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SX Laptop 
Portable 
Computer 



Leo Suarez , Frank Canova, and 
Neil Katz 
IBM Corporation 
Boca Raton , Florida 

Portable computers are not new to 
the industry, and until recently 
have been plagued with many 
limitations, such as size, weight, 
usability, and enough horsepower 
to match their desktop counter¬ 
parts. With rapid advances in low- 
power logic, small lightweight 
DASD, and advances in flat-panel 
technology, the time was right to 
introduce the PS/2 Model L40 SX 
Laptop Portable Computer, a unit 
that matches its desktop 
counterparts. 

Market studies have shown that 
customers are looking for powerful, 
Intel 80386SX-based machines, with 
a minimum of 40 MB of hardfile ca¬ 
pacity, a 1.44 MB diskette drive, 
and enough onboard memory to run 
large, memory-intensive applications 
such as OS/2 or Windows®. 
Customers also require that the 
machine’s keyboard and screen be 
comfortable to use. 

Another requirement is that ma¬ 
chines are battery-operated for true 
portability. Another is expansion ca¬ 
pability - the ability to add commu¬ 
nication cards, additional DASD, or 
a SCSI card. Finally, customers ex¬ 


pect all these features in a small 
lightweight package that can easily 
fit inside a briefcase. 

Hardware Overview 

The PS/2 Model L40 SX is a high- 
performance Intel® 80386SX™, 20 
MHz-based laptop portable com¬ 
puter. It is designed around a chip 
set that has been optimized to re¬ 
duce the total number of external de¬ 
vices required to implement a 
complete IBM AT®-bus (non-Micro 
Channel®) computer. 

The L40 SX comes standard with 2 
MB of dynamic random access mem¬ 
ory (DRAM) expandable up to 18 
MB via two single in-line memory 
module (SIMM) sockets. The stan¬ 
dard storage devices in the L40 SX 
are a 3.5-inch, 2 MB (1.44 MB for¬ 


matted) superslim floppy diskette 
drive, and a 60 MB, 2.5-inch hard 
disk drive with 19 millisecond (ms) 
average seek time. 

Integrated into the machine is a 640 
by 480, VGA-compatible, mono¬ 
chrome, side-lit, super twisted ne¬ 
matic liquid crystal display (STN 
LCD) with 32 addressable grey 
scales. A full-function keyboard is 
also integrated into the base ma¬ 
chine. Included is a separate nu¬ 
meric keypad that, when positioned 
next to the computer, provides the 
user with a complete 101-function 
keyboard. 

The ports include a 9-pin serial port, 
25-pin parallel port, external VGA 
monitor port, a combination mouse 
or numeric keypad port, and an ex- 
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temal expansion port for docking- 
station connectivity. Internal plug-in 
options for the L40 SX include 2 
MB, 4 MB, or 8 MB SIMMs that 
plug into two SIMM sockets. 

Also, a local internal bus provides 
the interface required for either an 
optional RS-232D serial adapter or a 
2400 bps Hayes®-compatible 
modem with an integrated 9600 bps 
fax. The entire system is powered by 
either a 40 watt external AC/DC 
adapter or an internal 26 watt-hours 
(W-Hr) nickel cadmium recharge¬ 
able battery. With a second, smaller 
nickel cadmium battery, users can re¬ 
move the main battery without shut¬ 
ting off the computer. With this 
feature, users can plug in a fresh bat¬ 
tery or AC/DC adapter if the main 
battery runs out of power. 

The L40 SX power management sys¬ 
tem allows users to turn off unused 
subsystems such as the diskette 
drive or external ports. This, in turn, 
optimizes battery life for individual 
applications. The power manage¬ 
ment system is powerful enough to 
shut down sections of logic between 
keystrokes. 

Other options available include: 

• A battery quick charger, which re¬ 
charges batteries in less than 2.5 
hours 

• An automobile adapter, which op¬ 
erates the L40 SX from a ciga¬ 
rette-lighter socket 

• A mouse/trackball device, which 
integrates the features of a mouse 
and trackball into a small package 

• A premium carrying case with 
room for adapters, diskettes, and 
notebooks 

The entire system is contained in a 
12.8-by-10.7-by-2.1-inch package 
weighing only 7.7 pounds. 


Description 

System Board: The model L40 SX 
system board contains the logic nec¬ 
essary to support a fully compatible 
IBM PC. The system board includes 
the system processor, a coprocessor 
socket, 2 MB of DRAM, AT bus 
control logic, video control logic, 
video RAM, external I/O connec¬ 
tors, and a power supply. All the 
logic is contained in a system board 
measuring 10 inches by 12 inches. 
The system board is divided into 
five sections, as shown in Figure 1. 

The first section contains the proces¬ 
sor, core logic, and all DRAM. The 
core logic consists of three highly in¬ 
tegrated VLSI chips. The largest of 
the chips, which contains the system 
processor control, memory control, 
and power management logic, con¬ 
tains nearly 30,000 gates. The sec¬ 
ond core logic chip contains two 
serial ports and a single parallel 
port, while the third core logic chip 
contains a floppy disk controller, sys¬ 
tem realtime clock, and Integrated 
Drive Electronics (IDE) for the 
hardfile interface. All chips are de¬ 
signed with a power control logic 
feature. This feature allows: the de¬ 
vice to be clocked down to 0 MHz; 
portions of the device to be indepen¬ 
dently powered down; or the device 
to be totally powered down. 

The second system board section 
contains the video control circuits. 
This logic consists of a single VGA 
controller chip that can drive either 
the system internal LCD display or 
an external VGA-compatible CRT. 
The video controller chip handles all 
display buffer management func¬ 
tions, including display refresh cy¬ 
cles, memory refresh cycles, and the 
arbitration of host access cycles. In¬ 
cluded with the video controller chip 
is an integrated random access mem¬ 
ory digital-to-analog converter 


(RAMDAC). The RAMDAC has a 
256-by-18-bit color lookup table 
with triple six-bit, digital-to-analog 
(D/A) converters that provide the 
three analog signals (red, green, and 
blue) to the video display connector. 
The video controller contains the 
logic that maps colors to 32 grey 
scales for display on the system’s 
LCD. 

The third section contains the sys¬ 
tem I/O connectors. These connec¬ 
tors consist of the standard PS/2 
connectors - a single external serial 
port, parallel port, video connector, 
AT bus expansion connector, power, 
and external numeric keypad or 
mouse connector. The many connec¬ 
tors on the system board connect the 
system board and the various inter¬ 
nal system devices. The internal de¬ 
vices connected are the LCD panel, 
floppy diskette drive (FDD), hard 
disk drive (HDD), SIMMs, internal 
data/fax modem or second serial 
port, internal keyboard, and battery. 

The fourth section contains the user 
input subsystem (UIS). The UIS al¬ 
lows the computer to monitor the 
system in which it is operating. UIS 
supports numerous interfaces, includ¬ 
ing one that allows the system to ac¬ 
cept user input from the keyboard 
and keypad, and for the system to 
sense its own environment. UIS func¬ 
tions are controlled by a second mi¬ 
croprocessor unit, called the Slave 
Micro-Control Unit (SMCU). The 
SMCU performs the scanning func¬ 
tion for the internal keyboard. It also 
supports the external numeric key¬ 
pad or mouse. As the SMCU is driv¬ 
ing the keyboard scanning matrix, it 
simultaneously performs a number 
of other functions. The SMCU moni¬ 
tors the battery voltage and tempera¬ 
ture, and determines whether to turn 
on the battery-charging circuits and 
to execute an algorithm that deter¬ 
mines the amount of energy remain- 
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Figure 1. L40 SX System Board Components 


ing in the battery. The SMCU also 
controls the system icon status indi¬ 
cator panel. The SMCU also reads 
the temperature via its onboard A/D 
converters, and its humidity sensors 
determine if the machine’s internal 
environmental conditions are operat¬ 
ing within range. 

The last section is the DC/DC power 
supply, which provides all DC 
power to the system logic, modem, 
and LCD display. The power subsys¬ 
tem is a simple and efficient (85 per¬ 
cent) bucking regulator that receives 
its power from either the internal bat¬ 
tery pack or external power such as 
the system AC adapter. Total inter¬ 
nal maximum power consumption is 
40 watts. 

During AC operation, the internal 
system battery pack is recharged, in¬ 
dependent of system operation. The 
power subsystem is designed to en¬ 


sure uninterruptible power in case of 
failure. If AC power is lost, the 
main battery pack takes over, allow¬ 
ing system operation to continue. 

There is a small sub-battery within 
the power subsystem. This battery 
provides system power when the 
main battery is being replaced. The 
sub-battery is continuously re¬ 
charged, allowing for multiple 
standby operations. 

Hard Disk Drive: The L40 SX 
uses a 2.5-inch, low-power, low- 
weight, hard disk drive. The drive 
has an integrated onboard AT con¬ 
troller that interfaces directly with 
the WD76C21, which has 16-bit In¬ 
tegrated Drive Electronics incorpo¬ 
rated in the chip. 

The drive has been optimized for 
portable applications: low power, 
small footprint, and low weight. Key 


attributes of this hard disk drive are 
60 MB minimum formatted capacity 
and typical 19 ms average seek time. 

The hard disk drive has unique 
power management features that 
allow the system to power down sec¬ 
tions of the drive such as the motor, 
logic, or both. This is critical, be¬ 
cause the machine must minimize 
power draw if its subsystems are not 
used. To power down the drive, spe¬ 
cific registers on the drive are ad¬ 
dressed that power off the logic, 
motor, or both. 

Diskette Drive: Similar to the hard 
disk drive’s criteria for weight, size, 
and low power, the floppy diskette 
drive also had the same limitations. 
The the only exception is that it had 
to be wider to accommodate the 3.5- 
inch medium. 
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Floppy diskette drive technology, 
however, has not evolved like that 
of hard disk drives with their on¬ 
board power management features. 
Therefore, L40 SX power manage¬ 
ment on the diskette drive is handled 
by the diskette controller features of 
the WD76C21 device. Whenever de¬ 
vices monitor no diskette activity, a 
timer counts down from user-set val¬ 
ues or the default value is set by the 
system. If no activity is encountered 
during this time, the +5 V power to 
the diskette is powered off. Upon de¬ 
tecting any activity, power is again 
supplied to the diskette drive and 
read/write access is allowed after the 
appropriate spin-up time has been 
achieved. 

Liquid Crystal Display (LCD): 

The L40 SX uses a super twisted ne¬ 
matic LCD with a color compensa¬ 
tion film to get a black-on-white 
screen. This compensation film also 
produces a high contrast ratio (20:1 
maximum, 12:1 typical). The display 
is a transmissive type with a high-ef¬ 
ficiency cold cathode fluorescent 
lamp (CCFL) side light. 

The display has 640-by-480 pixels 
of resolution (VGA). Each pixel is 
0.31 mm by 0.31 mm and generates 
a screen measuring 10 inches diago¬ 
nally. The display can be divided 
into four major sections: 

• Liquid crystal glass assembly 

• Row and column drivers that con¬ 
nect to the glass via flexible cables 

• Side-light and diffuser 

• Power inverter that provides 
power to the CCFL 

The side-light technique allows the 
display thickness to be kept to a min¬ 
imum (10 mm maximum), allowing 
the overall machine thickness to be 
reduced. The high-efficiency CCFL 
also allows high illumination for low 


power. Typical power dissipation at 
50 candelas/meter square is 3.5 
watts. This is the total power of the 
display, including the CCFL, in¬ 
verter, and drivers. The display has 
onboard logic to display 16 grey 
scales with Gamma correction. How¬ 
ever, with the use of the WD90C20 
VGA Flat Panel Controller, the sys¬ 
tem can address up to 32 grey scales. 

Keyboard: The L40 SX keyboard 
has 84 rubber-domed keys. The key¬ 
board layout is compatible with 
IBM’s G-101 keyboard layout. 

When the standard numeric keypad 
is placed next to the L40 SX system 
unit, the keyboard layout is identical 
to that of the IBM G Keyboard. 



The fax utility lets users 
transmit, receive, or view 
a faxed image, which can 
be shown on the system 
display or sent to one of 
the printers 


A basic requirement was to make 
typing on the keyboard easy. This 
meant that the travel between keys, 
typing angle, and keyboard height 
must be compatible with existing 
IBM keyboards. The keyboard typ¬ 
ing angle was designed to be five de¬ 
grees, travel was set at 3 mm, and 
the height at the home row was de¬ 
signed at 30 mm. These factors 
made the L40 SX system slightly 
larger than competing laptops. It 
also made the L40 SX significantly 
more usable as a data entry device 
than competitive models. 


Data/Fax Modem: The portable 
system’s design must also allow for 
connectivity to a variety of data and 
image facilities. The internal 
data/fax modem for the PS/2 L40 
SX provides this connectivity. This 
modem is a highly compact, two- 
inch-by-six-inch card that contains 
all the logic for a V.29 9600-bps fax 
send/receive modem, as well as a 
2400 bps, V.22 bis data modem. To 
improve operation efficiency, the 
data modem supports the MNP™ 4 
& 5 protocols, allowing for error cor¬ 
rection and data compression when 
communicating with another MNP 4 
& 5 modem. With some types of 
data, effective data transmission 
speeds as high as 4800 bps can be re¬ 
alized with these MNP protocols. 

The modem is designed to minimize 
its power draw. When not in use, all 
modem functions are powered off; 
turning on Data Terminal Ready 
(DTR) powers up the modem. The 
modem also powers up the system if 
the system is suspended and the 
modem detects an external ring from 
a calling device. 

Included with the modem is a 
simple-to-use fax utility. It lets users 
transmit, receive, or view a faxed 
image, which can be shown on the 
system display or sent to one of the 
printers. 

An optional RS-232D card satisfies 
other countries’ widely different re¬ 
quirements for modem/fax functions. 
This card plugs into the same local 
bus as the modem/fax card and al¬ 
lows external, country-specific mo¬ 
dems to be attached to the L40 SX. 
With this card, users can add a sec¬ 
ond serial port to the machine if a 
modem/fax feature is not required. 
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Power Management 

Power management of the L40 SX 
is the heart of what makes it a 
laptop and is pervasive in its system 
design. Special power-saving de¬ 
signs used throughout the machine 
determine when to reduce or elimi¬ 
nate power to various areas of the 
system. No other PS/2 model does 
this. 

The L40 SX has many power man¬ 
agement features. Some are auto¬ 
matic, and users are unaware that 
power is being adjusted within the 
system. Others are controlled only 
by some specific action. 

Sleep Mode: Sleep mode is the 
heart of the core logic’s power man¬ 
agement while applications are run¬ 
ning. Normally, the system 
processor executes an application at 
20 MHz. However, with complemen¬ 
tary metal oxide semiconductor 
(CMOS) technology, power con¬ 
sumption is proportional to system 
frequency. Therefore, every opportu¬ 
nity is taken to reduce the system 
frequency transparently. Sleep mode 
is used as long as the economy 
switch is set to Automatic (A). 

There are two types of sleep modes - 
high-performance and long battery 
life. The set features utility deter¬ 
mines which type of sleep mode will 
occur. Although the default is “high 
performance,” the mode can be ad¬ 
justed depending on application 
requirements. 

For the long battery life sleep mode, 
the core logic can reduce system 
speed to 5 MHz. If I/O activity does 
not occur after some predetermined 
time, the system processor speed 
will be lowered. The amount of time 
that the device must be idle is differ¬ 
ent for various types of devices. The 
length of time for the system to re¬ 
main at 20 MHz ranges from one 



second on a HDD interrupt to only 
1 ms on a video write. The system is 
tuned so database applications using 
the hard disk extensively, and text 
editors using the keyboard and 
mouse, will not see any apparent per¬ 
formance difference as the system 
processor speed changes. 

The second phase occurs for either 
high-performance or long battery 
life sleep modes. When the applica¬ 
tion is idle, it may call one of sev¬ 
eral BIOS or OS/2 services. Special 
power management BIOS code 
waits for these calls. When one oc¬ 
curs, the BIOS reduces the support 
logic’s clock to 0 Hz and turns off 
system processor power. An OS/2 
device driver performs an equivalent 
function. 


Turning off power to the system pro¬ 
cessor is no small matter. All vital 
system processor registers must be 
saved in an extended BIOS data 
area. Any interrupt that occurs re¬ 
verses the process, and the system 
processor continues executing as if 
nothing happened. This process 
takes less than 90 microseconds and 
prevents any loss from high-speed 
data transfers. 

A BIOS function at Interrupt 15h, 
AH=41h, is available for applica¬ 
tions that can predict when they will 
be idle. If used by an application, 
the BIOS function helps extend bat¬ 
tery life. When called, the L40 SX 
immediately reduces the support 
logic’s speed to 0 Hz, saves the sys¬ 
tem state, and powers off the system 
processor. It returns from this call 
when any interrupts occur (timer 
ticks, keys pressed, and so forth). To 
the application, it appears like a No 
Operation (NOP). The BIOS call 
can be used on any personal com¬ 
puter or PS/2 and is ignored if 
power management is not imple¬ 
mented. If used, the extra power sav¬ 
ings can extend any laptop’s battery 
life. 

A unique power management pro¬ 
gram is active under OS/2. This pro¬ 
gram is run as the lowest priority 
task. When this program is called, a 
check is made to see whether the 
time that the program is called is 
less than the minimum time for an 
OS/2 time slice. If it is, then a sys¬ 
tem sleep mode is requested. This 
way, OS/2 users can extend battery 
life like DOS users. 

I/O Sleep: I/O devices also use a 
significant portion of the system 
power. Both automatic timeouts and 
user controls allow I/O devices to be 
powered off. 
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Like the core logic timeout, the I/O 
devices automatically shut off if not 
used within a predetermined time. 

The timeouts for the LCD, hard disk 
motor, and the entire system can be 
adjusted from one minute up to 20 
minutes with the set features utility. 
The maximum timeout is device-de- 
pendent. Timeouts can be disabled 
by setting them to 0 minutes. In addi¬ 
tion, the floppy disk controller and 
drive electronics turn off if not ac¬ 
tive within two seconds. 

The LCD and hard disk motor 
timeouts are created with timers 
built into the core logic and inte¬ 
grated drive electronics, respec¬ 
tively. The LCD timer is reset with 
any keyboard or mouse interrupt, 
and the hard disk timer is reset with 
any disk activity. The system 
timeout, however, is created by the 
power management BIOS, which 
counts “watchdog” interrupts from 
the SMCU. This IRQ 11 interrupt is 
generated by the SMCU every 100 
ms whenever the system timeout is 
enabled. 

User controls are provided to turn 
off the built-in serial and parallel 
ports as well as the optional data/fax 
modem or second serial adapter. 
When the serial ports are powered 
off, the associated RS-232D drivers 
are also powered off. Because the se¬ 
rial and parallel ports use the same 
core logic chip, the chip remains ac¬ 
tive as long as any one of the de¬ 
vices is on. However, when all serial 
and parallel ports are off, the chip is 
put into a special low-power standby 
state with all clocks turned off. 

Finally, the VGA contains a digital- 
to-analog converter (DAC), which is 
required only when an external CRT 
is attached. When the CRT is not 
connected, the DAC is automatically 
powered off, which further reduces 
system current. 


Suspend and Resume: Suspend 
and resume adds convenience to the 
L40 SX. With it, you can immedi¬ 
ately turn off the system without los¬ 
ing data and restarting it quickly 
without rebooting. 

The suspend operation stops the sys¬ 
tem processor, turns off all possible 
devices, and freezes the system state 
in DRAM. The DRAM is put into a 
slow (64 ms), low-power refresh 
while suspended. The DRAM and 
its support logic are the only compo¬ 
nents where power remains on. 

When the system resumes, the entire 
system state is restored, and the ap¬ 
plication continues as if it never 
stopped. 



Suspend and resume adds 
convenience to the 
L40SX. 


Suspend can be initiated as a result 
one of the following: 

• Closing the lid 

• Reaching system timeout 

• The SMCU detecting a low bat¬ 
tery condition 

• The SMCU detecting that the tem¬ 
perature limit has been exceeded 

Resume can be initiated from open¬ 
ing the lid, an interrupt from the 
Real Time Clock (RTC), or by ring¬ 
ing the data/fax modem. 

All events that create a suspend are 
directed through the IRQ 11 inter¬ 
rupt. Before entering suspend, power 
management BIOS ensures that all 
I/O devices are in a stable state. 


which is done by checking for pend¬ 
ing interrupt or DMA activity. If any 
device has not finished being ser¬ 
viced, BIOS requests that the SMCU 
retrigger the suspend request a short 
time later. This retriggering is nor¬ 
mally not visible, but continues as 
long as I/O activities are in progress. 
The BIOS suspend request guaran¬ 
tees that data transfers have stopped 
and no data will be lost. 

For the system processor, suspend is 
similar to the sleep mode. The sys¬ 
tem processor state is saved in an ex¬ 
tended BIOS data area, then 
powered off, and the clock for the 
system processor support logic is set 
to 0 Hz. The remainder of the sup¬ 
port logic is also shut down upon dis¬ 
abling all clocks. Only the 32 KHz 
clock for the Real Time Clock 
(RTC) remains on. In this condition, 
the entire quiescent current for all 
system board logic totals just a few 
milliamperes. The 32 KHz clock is 
routed to the memory controller to 
create a slow (64-ms) refresh to con¬ 
serve power. Standard high-powered 
DRAMs cannot support this slow re¬ 
fresh; therefore, the L40 SX SIMMs 
have a special key that prevents stan¬ 
dard DRAMs from being used 
accidentally. 

For the VGA, the slow 32-KHz re¬ 
fresh is also routed to the VGA con¬ 
troller for the VRAM. In addition, 
the contents of the palette registers 
within the RAMDAC are saved 
within the extended BIOS data area 
before its power is turned off. Power 
is removed because the DAC portion 
contains analog circuits that draw 
current even when not clocked. Sim¬ 
ply removing the clocks to that por¬ 
tion would not save sufficient power 
for suspend. All other VGA clocks 
are disabled so the other CMOS 
logic on the chip sits idle at its quies¬ 
cent current. 
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For other I/O devices, suspend is 
mostly a matter of powering them 
off. Special care must be given, how¬ 
ever, to resuming the device. For ex¬ 
ample, in the floppy disk controller, 
all parameters are held in a static 
powered-on chip during suspend. 
Therefore, none of these parameters 
need be saved. For the data/fax 
modem, however, the modem’s pa¬ 
rameters set up by the user cannot 
be predicted. Therefore, they must 
be saved before all modem logic is 
powered off. A special mechanism 
is built into the data/fax modem for 
the sole purpose of dumping the 
modem’s state prior to the suspend 
mode and restoring it for the resume 
mode. 

Once all of the system state is safely 
saved to memory, a special “shut¬ 
down code” is saved in CMOS, a 
tone sounds, the suspend icon is illu¬ 
minated, and the SMCU turns itself 
off by halting and stopping its own 
oscillator. This is done to save even 
more power. During suspend mode, 
attaching an AC adapter causes only 
the SMCU to wake up. This happens 
because the SMCU also supports the 
algorithm used to properly charge 
the NiCd battery. 

To resume, a system reset occurs. 
POST first checks the previous shut¬ 
down code in CMOS to determine 
what caused the reset. Seeing that 
the last action was a suspend, it be¬ 
gins restoring all of the system state 
saved to the extended BIOS data 
area. The last thing restored is all of 
the system processor registers used 
by the application. POST then re¬ 
turns from the interrupt that origi¬ 
nally created the suspend, and the 
application continues exactly where 
it left off. 

Under OS/2, a unique power man¬ 
agement device driver is active. This 
driver supports the suspend and 


SMCU hardware interrupts, and 
guarantees that additional 80386 pro- 
tected-mode registers are safely 
saved. With this driver, suspend and 
resume operate in OS/2 just like 
they do in DOS. 

Environmental Factors 

Portable computers are exposed to a 
rougher environment than other com¬ 
puters because they can be moved 
easily and used anywhere. There¬ 
fore, the L40 SX was designed to 
survive rough treatment as well as 
extreme temperature, humidity, and 
pressure swings. For example, tak¬ 
ing the computer from the back seat 
of a car during the summer and 
going inside an air-conditioned room 
entails great temperature change, 
which can cause severe damage to 
many of the subsystems. The ma¬ 
chine should not be used outside of 
its specified operating range of +5° 
to +35° Celsius (41° to 95° 
Fahrenheit). 

Moving a machine from a hot to 
cold environment or using it where 
condensation can form could se¬ 
verely damage many of its parts. As 
a safeguard, the L40 SX was de¬ 
signed to detect the internal tempera¬ 
ture of the machine and the 
humidity. This was accomplished by 
adding a thermistor and dew sensor 
that are continuously monitored on 
the SMCU. Data is interpreted differ¬ 
ently by the SMCU, as shown in 
two sample operating conditions. 

Condition # 1: 

The system is off and is turned on. 

When temperature or humidity lim¬ 
its, or both, have been exceeded, the 
machine immediately goes into a 
halt state and the system will not op¬ 
erate. In this case, the temperature 
or dewpoint icon, or both, turns on. 
The system stays in this state until 


the internal machine temperature or 
humidity, or both, are within the 
machine’s operating limits. This can 
be likened to a Power-On Self Test 
(POST) error, except that in this 
case none of the subsystems is 
turned on and the logic is only par¬ 
tially on. 

Condition # 2: 

The system is being used, and the 
temperature or humidity limit, or 
both, is reached. 

If the machine’s internal temperature 
drops below 5° C, the temperature 
icon turns on and the machine goes 
into a suspended state. The icon will 
not turn off and allow the machine 
to exit its suspended state until the 
temperature rises above 6° C. Con¬ 
versely, when the internal tempera¬ 
ture exceeds 46° C, the temperature 
icon turns on, and the main battery 
stops charging. The internal tempera¬ 
ture must drop below 44° C before 
the icon is turned off. When the in¬ 
ternal temperature reaches 52° C, the 
machine goes into suspended mode 
and will not come out of it until the 
temperature reaches 44° C. 

If the inside of the machine exceeds 
94 to 97 percent relative humidity, 
the dewpoint icon warns the user of 
the hazard. But unlike the tempera¬ 
ture sensor, this condition will not 
put the machine into the suspend 
mode. The icon stays on until the hu¬ 
midity inside the system decreases 
to between 80 and 93 percent rela¬ 
tive humidity. 

The system was also designed to 
minimize the number of mechanical 
parts. When compared to other 
laptops available today, the L40 SX 
has significantly fewer parts. This al¬ 
lows the machine to withstand more 
operational shock and vibration, and 
damage from most accidents. 
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Battery Controls 

The SMCU monitors the NiCd bat¬ 
tery to create a battery fuel gauge on 
the icon panel. This function is a 
complex process, which relies on dy¬ 
namically monitoring the battery 
voltage, current, and temperature as 
the system operates. The voltage 
discharge profile for a NiCd battery 
falls steeply during the first few mo¬ 
ments of use after a full charge, is 
rather stable during the majority of 
its life, and becomes steep again just 
before it dies. The voltage also 
changes dramatically depending on 
system activity and the current being 
drawn. Also, the measurements must 
be filtered algorithmically to remove 
inaccuracies due to transients caused 
by changing loads. Finally, hystere¬ 
sis must be applied to prevent false 
readings. The final results are shown 
on the icon display. A low-battery 
condition may trigger warning tones 
from the SMCU or a suspend if the 
warning is ignored. 

The SMCU also controls the NiCd 
battery during the charging process. 
Charging characteristics of the bat¬ 
tery are built into the SMCU. It uses 
the difference between the ambient 
and the battery temperatures to calcu¬ 
late the rise in temperature within 
the battery, which resulted from 
charging. The SMCU also measures 
the voltage and overall charging 
time. The result is an optimum 
charge that helps prevent memory ef¬ 
fects from occurring. The SMCU 
also indicates from the icon display 
the status of the charge. 

Usability and Ergonomic 
Considerations 

Like many laptops, the L40 SX is de¬ 
signed with usability in mind. The 
keyboard layout, industrial design, 
and power management interface fea¬ 
tures were decided upon after exten¬ 
sive testing. 


In addition to the traditional hard 
disk and floppy disk access, the L40 
SX has many special features. An 
LCD icon status panel displays real¬ 
time information, including a 
modem/fax ring indicator, environ¬ 
mental state, speaker “on” for the 
hearing-impaired, battery fuel gauge, 
and suspend/resume state. All sys¬ 
tem connectors are placed in the rear 
of the machine behind latched doors 
that hide the connectors when not in 
use. 

Besides the L40 SX’s small size and 
low weight, the machine comes in a 
small, lightweight leather case con¬ 
toured for easy carrying, and has a 
removable shoulder strap. 

Because this machine can be used in 
a DC environment, its power man¬ 
agement system is designed to ex¬ 
tend battery life and to avoid 
accidental power loss. The battery 
fuel gauge icon has a three-stage in¬ 
dicator that provides audible and vis¬ 
ible feedback when the battery is 
low. Once activated, the system can 
be used until the battery dies. Once 
the battery dies, the system drops 
into suspend mode, saving the sys¬ 
tem environment and maintaining 
power to the system main memory. 
The user needs to remove only a 
main battery and install a new one. 
The system resumes exactly where 
the application left off. 

Summary 

The IBM PS/2 L40 SX gives users 
the flexibility of replacing their 
desktop machines with a truly porta¬ 
ble alternative. Users can now have 
desktop performance inside their 
briefcases and set up offices any¬ 
where. The function-packed L40 SX 
has the usability and power to sup¬ 
port computing requirements for 
many years to come. 
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OS/2 2.0 
Considerations 

IBM is planning to release a new 
version of OS/2 in the fourth- 
quarter 1991. In order for our 
customers to plan their future in¬ 
stallations, this article discusses 
features, positioning, application 
migration, and future directions 
for OS/2 2.0. 

IBM’s systems software strategy has 
been, and will continue to be, one of 
providing productive operating envi¬ 
ronments that meet our customers’ 
needs today and in the future. OS/2 
is an integral part of that strategy, 
and IBM is firmly committed to en¬ 
hancing OS/2 to meet our 
customers’ requirements and exceed 
their quality expectations. 

To support personal systems, DOS, 
DOS/Windows, and OS/2 are avail¬ 
able. These operating systems 
should be selected based on individ¬ 
ual workstation environments and 
usage requirements. 

DOS will remain a viable operating 
system for many years for entry- 
level usage. Windows 3.X has en¬ 
hanced DOS with a graphical 
interface and the ability to run multi¬ 
ple DOS applications on 386- and 
486-based systems. 

OS/2 1.3 is ideally suited for 286, 
386, and 486 users with intermediate 
and advanced-level usage require¬ 
ments. Its memory requirement of 
only 2 MB makes it ideal as a client. 


9_ 

Software 


OS/2 2.0 will be a robust operating 
system for 386 and 486 users. It will 
run multiple DOS, Windows, and 16- 
bit and 32-bit OS/2 applications con¬ 
currently. It will include a new 
object-based graphical OS/2 2.0 
shell to exploit 32-bit hardware tech¬ 
nology. In other words, IBM is build¬ 
ing a technologically superior 
product in OS/2 2.0 that will be the 
“integration platform” on which our 
customers will execute their current 
software while developing 32-bit ap¬ 
plications. IBM intends to make 
OS/2 2.0 available in the 
fourth-quarter 1991. 

Features Comparison 

OS/2 2.0 and Windows 3.0 appear 
similar, and both: 

• Have a graphical user interface 
(GUI) 

• Enable applications to take advan¬ 
tage of larger memory in pro¬ 
tected mode 

• Provide concurrent execution of 
multiple applications 

• Support execution of multiple 
DOS sessions 

There are, however, significant dif¬ 
ferences. In order to make the infor¬ 


mation as current as possible, the ex¬ 
pected capabilities of Windows 3.1, 
as made public by Microsoft, will be 
used in this comparison. 

Usability: OS/2 2.0 and Windows 
3.1 will be very usable products, and 
both provide: 

• Graphical installation that takes 
maximum advantage of the bene¬ 
fits of the graphical user interface 
(GUI) 

• An object-based interface with a 
drag or drop environment that is 
consistent across the system 

• Support for accessing LAN re¬ 
sources, built directly into the 
shell 

• Intelligent font technology 

• Support for a large number of 
printers 

• An interactive tutorial 

• Simple productivity applications, 
games, and utilities (users can 
learn the system and get to work 
right away) 

OS/2 2.0 will include a superset of 
those provided with Windows 3.1. 
However, there are differences 


This paper discusses future products or future releases of products currently 
commercially available. The discussion regarding Windows™ is based upon 
information that the Microsoft® Corporation has made publicly available and is 
subject to change. The descriptions and discussion of IBM’s future products, 
performance, functions, and availability are based upon IBM’s current intent 
and are also subject to change. 

Unless specifically qualified as IBM DOS, any use of DOS in this article refers 
generically to both IBM DOS and MS-DOS®. 
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between the two. Some usability fea¬ 
tures unique to OS/2 2.0 are: 

• An enhanced user interface, 
known as the OS/2 2.0 new shell, 
built on Presentation Manager™ 
(PM) and built around the notion 
of objects 

• Extensive on-line help and 
context-sensitive help for the 
system 

• Support for long file names in the 
High Performance File System 

• File system support for object- 
oriented features by means of ex¬ 
tended attributes (EAs) 

Of all these differences, the most sig¬ 
nificant for use on the system is the 
OS/2 new shell. It represents a sig¬ 
nificant advancement in the GUI 
desktop environment. 

The current OS/2 1.3 shell consists 
of five logical units: 

• Desktop Manager 

• File Manager 

• Print Manager 

• Control Panel 

• Task List 

The OS/2 2.0 shell has been rede¬ 
signed to give users a single inter¬ 
face to manage multiple types of 
objects, including devices (printers 
and drives), files, and programs. 

Each defined printer or attached 
drive is a separate icon. These ob¬ 
jects can be arranged on the desktop 
or in specific shell windows. Users 
can interact with the objects using a 
well-defined drag and drop environ¬ 
ment and manipulate files without 
concern for the file directory hierar¬ 
chy. However, if the user wishes, 
multiple directory trees can be ac¬ 
cessed simultaneously. Views, selec¬ 
tion techniques, and actions are 
consistent throughout the shell. 


The desktop contents and shell are 
saved at shutdown and restored at 
start-up, preserving the continuity of 
the work. Applications can be inte¬ 
grated with the shell. An application 
object can be the source of a drag to 
the shell, and an application window 
can be the target for a drag from the 
shell. When the user acts on an appli¬ 
cation object from the shell, the asso¬ 
ciated application defines how the 
object will respond via a dynamic 
link function. The shell provides de¬ 
fault-handling for most actions on 
file objects. 



The OS/2 2.0 shell has 
been redesigned to give 
users a single interface to 
manage multiple types of 
objects. 


Software Technology: Figure 1 
shows how some of the underlying 
technologies in OS/2 2.0 and Win¬ 
dows 3.1 affect use of the system. 
Windows is configured in 386 en¬ 
hanced operation mode, which maxi¬ 
mizes its capabilities, and is the 
default on a 386 or 486 system with 
at least 2 MB of memory. 

Memory technology is fundamental 
to understanding how large an appli¬ 
cation can be, how much data it can 
handle, and how many applications 
can be harnessed simultaneously to 
obtain the needed solution. Memory 
management in OS/2 and Windows 
leads to some complex technical con¬ 
siderations. IBM believes that OS/2 
2.0 will provide a much larger and 


more flexible upper limit than 
Windows 3.1. 

Systems implementing virtual paged 
memory, as both OS/2 2.0 and Win¬ 
dows 3.01 will do, have two types 
of memory limits. These limits are 
physical memory installed and vir¬ 
tual memory for running applica¬ 
tions that affect how many 
applications can be loaded and run 
concurrently. Even though applica¬ 
tions see only virtual memory, physi¬ 
cal memory remains important. This 
is because performance degrades as 
the amount of virtual memory used 
begins to exceed the amount of phys¬ 
ical memory installed. Because vir¬ 
tual memory is paged into physical 
memory by the operating system 
when needed, and if there is not 
enough physical memory, the system 
spends more time shuffling memory 
pages and less time running applica¬ 
tions. The optimum ratio of virtual 
memory to physical memory is 
highly dependent upon the way ap¬ 
plications are written and used. 

While Windows 3.0 supports a maxi¬ 
mum 16 MB of physical memory, 
both OS/2 2.0 and Windows 3.1 are 
intended to support greater than 16 
MB, up to the physical limits sup¬ 
ported by the hardware. This leaves 
plenty of room for growth, because 
Windows 3.1 and OS/2 2.0 are ex¬ 
pected to need only 3 to 6 MB of 
physical memory. For Windows, the 
maximum amount of virtual memory 
shared across all applications is lim¬ 
ited to four times the amount of 
physical memory installed, subject 
to available disk space. In OS/2 2.0, 
the limit on virtual memory is the 
amount of available disk space. 

Each application running under 
OS/2 2.0 has a 512 MB limit with 
up to 240 applications running and 
no limit on the total virtual memory 
used. 
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Windows 3.1 

OS/2 2.0 

Physical memory limit 

> 16 MB 

> 16 MB 

Virtual memory limit 

4 X physical 

512 MB (disk space) 

Memory model 

Segmented (64 KB) 

Flat memory objects 

Multitasking - DOS applications 

Time slicing 

Pre-emptive time slicing 

Multitasking - Windows/PM applications 

Cooperative 

Pre-emptive time slicing 

Priority 

Static (set by user) 

Dynamic 

Dispatchability 

Process 

Thread 

System services 

Serial 

Parallel 

Protection between applications 

Unprotected 

Protected 

Kernel protection - DOS applications 

Unprotected 

Protected 

Kernel protection - Windows/PM applications 

Protected 

Protected 

File system 

FAT 

Enhanced FAT HPFS installable 

Reliability/availability/service support 

None included in 3.0 

Stand-alone dump error 

Logging trace utilities 


Figure 1. Windows 3.1 and OS/2 2.0 Technology Comparison 
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Just as important as the maximum 
virtual memory is the model for man¬ 
aging it. Windows 3.1 probably will 
continue to use a segmented mem¬ 
ory model that deals with memory 
as pieces in any size up to 64 KB. 
OS/2 2.0 deals with memory as com¬ 
plete objects of whatever size is 
needed, up to the size of virtual 
memory. Windows’ segment size 
constrains the maximum number of 
many resources used by applications 
or Windows itself. An example is 
the number of windows that can be 
opened simultaneously within an ap¬ 
plication, which typically is about 
10. In Windows, these maximums 
are equal with the virtual memory 
size, which limits the number and 
size of applications. The flat 32-bit 
memory objects provided by OS/2 
2.0 avoids the constraints imposed 
by segmentation. For other reasons, 
resource maximums still occur in 
OS/2 2.0. These maximums are 
larger and not the result of a fixed 
constraint imposed by the memory 
technology. 

The memory technology in Win¬ 
dows 3.1 should continue to provide 
relief from many of the constraints 
imposed by DOS. Windows 3.1 will 
retain memory technology limits that 
are less than the 386 hardware capa¬ 
bility. OS/2 2.0 memory technology 
takes advantage of the hardware. For 
example, consider a system with 4 
MB of physical memory. Under 
Windows 3.1, there is an absolute 
limit at 16 MB of virtual memory. 
Applications needing even one more 
byte of memory will not run. 

With OS/2 2.0, there is no absolute 
limit at 16 MB, although with only 
4 MB of physical memory, some per¬ 
formance limit would be reached be¬ 
fore attaining the virtual memory 
limit of 512 MB. However, in OS/2 
2.0, this performance limit is soft, in 
the sense that performance slows 


down as more virtual memory is 
needed, yet the application continues 
to run. This is an oversimplification, 
because limits other than virtual 
memory size may also apply. OS/2 
2.0 should provide a significant ad¬ 
vantage in removing memory as a 
constraint on what users and the ap¬ 
plication developers can achieve. 



OS/2 2.0 has advantages 
in its file system design. 


The series of items on multitasking, 
priorities, dispatching, and system 
services are all closely related. The 
significance is the smoothness with 
which the system operates, and the 
responsiveness that applications can 
exhibit. On lightly loaded systems, 
both approaches should work well. 
The OS/2 2.0 technology should bet¬ 
ter support heavy workloads. This is 
especially important with high-speed 
concurrent communications pro¬ 
grams. Multitasking allows users to 
continue with something new while 
the system is completing the previ¬ 
ous task. A simple, instructive exper¬ 
iment would be to spool a large file 
to the printer in Windows 3.X from 
the file manager or a Windows appli¬ 
cation, then switch to another appli¬ 
cation and continue working. 
Compare this with the equivalent op¬ 
eration on OS/2 2.0, and judge the 
relative smoothness and 
responsiveness. 

OS/2 2.0 is intended to be a very sta¬ 
ble platform to use. OS/2 2.0 utilizes 
the processor’s protection features to 
protect applications from each other 
and the operating system kernel 


from the applications. One limitation 
of OS/2 1.3 was the lack of protec¬ 
tion of the system as a result of 
DOS application errors. This limita¬ 
tion is removed on OS/2 2.0. The 
worst possible application error that 
could occur in OS/2 2.0, which 
would be in rare instances, would be 
to hang up the application itself. 
Moreover, no application interferes 
with any data in memory that is pri¬ 
vate to another application. 

Although the Windows 3.X kernel 
enjoys some protection from applica¬ 
tions, all Windows applications exe¬ 
cute in the same address space and 
are not protected from each other. 
Windows 3.X applications risk en¬ 
countering data integrity problems 
because an addressing error in one 
application could modify data pri¬ 
vate in another and be undetected. 
Likewise, key portions of the Win¬ 
dows 3.X kernel can be overwritten 
by a DOS application, resulting in 
the unknown application error 
(UAE) message and a request to 
reboot the system. The importance 
of having good protection is clear to 
anyone who has lost work from mul¬ 
tiple applications because one of 
them managed to hang the system. 

OS/2 2.0 has advantages in its file 
system design. First, file systems are 
installable, simplifying support of 
new storage media requiring special¬ 
ized functions. An example is the in¬ 
stallable file system for CD-ROM. 
Second, OS/2 2.0 provides the High 
Performance File System. Its major 
features are: 

• Advanced strategies for laying 
files out on disk to minimize frag¬ 
mentation and maximize disk per¬ 
formance 

• Exploitation of SCSI hardware 
performance features 

• Sophisticated caching for reading 
and writing 
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• Support of very large disks 

• Support for long file names 

An enhanced FAT file system is sup¬ 
ported for floppy diskettes and for 
compatibility with existing hard 
disks already using FAT. Numerous 
performance improvements have 
been made relative to OS/2 1.3 and 
DOS while maintaining 
compatibility. 

Standard operating system support 
for reliability, availability, and ser¬ 
vice (RAS) is another attribute of 
OS/2 2.0. There are utilities to iso¬ 
late and log system software prob¬ 
lems. The benefit is that software 
service is integrated into OS/2 2.0. 
Windows 3.0 did not include any 
RAS-like features. As an environ¬ 
ment, OS/2 2.0 should provide many 
advantages, both in usability and in 
the robust technology underlying it. 

DOS Application Support: Be¬ 
cause of the large base of available 
DOS applications, it is necessary to 
focus on a detailed comparison of 
DOS application support. Figure 2 
shows a breakdown of the key envi¬ 
ronments, including DOS and OS/2 
1.3. Windows 3.0 was also included 
so several key measurements can be 
made. 

The comparison applies to operation 
on a 386 or both. Windows 3.0 is 
normally not run in real or standard 
mode on this class of machine, espe¬ 
cially if the emphasis is on DOS ap¬ 
plications. Those environments are 
included for reference, because real 
mode is required to run Windows ap¬ 
plications that have not been up¬ 
graded to support Windows 3.0. 
Standard mode may give better per¬ 
formance in systems with limited 
memory. 


The first group of entries relates to 
the raw memory space seen by the 
DOS application. Conventional mem¬ 
ory remains in an application after 
subtracting the memory “overhead” 
used by the system code. The values 
given are typical for a default instal¬ 
lation. IBM DOS 5.0 appears to 
have more conventional memory be¬ 
cause the default DOS installation 
does not include expanded memory 
(EMS) or mouse support. 



Standard operating 
system support for 
reliability, availability, 
and service is another 
attribute of OS/2 2.0. 


In Windows 386 enhanced mode, 
the default installation provides 
EMS support. The OS/2 2.0 default 
installation provides both EMS and 
mouse support. Including support for 
EMS (at 8 KB) and mouse (at 14 
KB) reduces the available conven¬ 
tional memory in DOS to 601 KB. 

In addition, any resident software or 
device drivers for functions such as 
LAN or host connectivity are sub¬ 
tracted from the conventional mem¬ 
ory available to DOS applications 
under DOS or Windows. However, 
they do not affect the memory avail¬ 
able in OS/2 2.0. 

This is illustrated by an example 
showing memory remaining with a 
LAN requester installed. EMS sup¬ 
port is through emulation of the 
EMS 4.0 specification out of ex¬ 
tended memory. Note that Windows 
3.0 has a fixed pool of memory allo¬ 
cated among all applications, while 


OS/2 2.0 has a separate, larger limit 
for each individual application. The 
OS/2 2.0 limit on extended memory 
available to a DOS application is 
based on using the extended mem¬ 
ory specification (XMS) interface. 
DOS applications using the DOS 
protected-mode interface (DPMI) 
specification can access up to 512 
MB of extended memory. 

The next group of entries covers 
memory management characteristics. 
Physical RAM describes the physi¬ 
cal memory locations available for 
loading the DOS application. Where 
only memory below 1 MB is avail¬ 
able, only one DOS application can 
be in memory at a time, and the 
other DOS sessions are swapped out 
to disk. 

“Memory overcommit” is the capa¬ 
bility to run applications needing 
more memory than is physically 
available on the machine. The nota¬ 
tion “none/switch” means that no in¬ 
dividual DOS application can 
overcommit memory, but the real 
mode portion can be moved to disk 
to make room for another DOS appli¬ 
cation. However, extended or EMS 
memory allocated by the application 
is not switched to disk. 

OS/2 1.3 can swap the DOS applica¬ 
tion to disk when running protected- 
mode applications. Windows 3.0 
386 enhanced mode can overcommit 
up to four times the physical mem¬ 
ory on the machine. OS/2 2.0 is lim¬ 
ited only by the amount of available 
disk space. 

Although the default is to swap 
through the file system, Windows 
386 enhanced mode allows a swap 
space to be preallocated, which 
leads to improved performance by 
avoiding the DOS file system. Be¬ 
cause all of this disk space is 
pre-allocated, none can be shared 
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IBM 

DOS 5.0 

OS/2 1.3 

Windows 3.0 on IBM DOS 5.0 

OS/2 2.0 

Real 

Standard 

Enhanced 

Conventional memory 
- with EMS and mouse 

623 KB 

601 KB 

529 KB 

558 KB 

571 KB 

569 KB 

633 KB 

Memory with LAN attachment 

543 KB 

486 KB 

478 KB 

491 KB 

489 KB 

633 KB 

DOS Extended Memory (XMS) 

16 MB 

none 

16 MB (total) 

16 MB (total) 

16 MB (total) 

16 MB (per 
application) 

DOS EMS 4.0 memory 

16 MB 

none 

16 MB (total) 

none 

16 MB (total) 

32 MB (per 
application) 








Physical RAM for DOS 

0 - 1 MB 

0 - 640 KB 

0 - 1 MB 

0 - 1 MB 

Any/Paged 

Any/Paged 

Memory overcommit 

None/Switch 

None/S wap 

None/Switch 

None/Switch 

4 x RAM 

Avail Disk 

Swap file 

File System 

File System 

File System 

File System 

Physical or 
File System 

File System 








Number of DOS applications 

16 

1 

16 

16 

16 

>32 

Background execution 

No 

No 

No 

No 

Yes 

Yes 








Invocation 

Shell/Cmd 

Icon 

Icon 

Icon 

Icon 

Icon 

Windowed 

No 

No 

No 

No 

Yes 

Yes 

Cut and paste 

No 

No 

Yes 

Yes 

Yes 

Yes 

Print spooling 

Yes 

Yes 

No 

No 

No 

Yes 

Installable file system 

No 

Yes 

No 

No 

No 

Yes 








Direct hardware access 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Timing-dependent 

applications. 

Foreground 

Foreground 

Foreground 

Foreground 

Exclusive- 
Mode Option 

Foreground/ 

Background 








DOS Protected-Mode Interface 

No 

No 

No 

No 

Yes 

Yes 

Virtual Control Program 
Interface and DOS Extenders 

Yes 

No 

No 

No 

No 

No 








Continues after Serious 
Application Errors 

Rarely 

Rarely 

Rarely 

Rarely 

Sometimes 

Usually 


Figure 2. Comparison of DOS Environments 


(Typical values for an IBM Model 8580-071) 
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dynamically. OS/2 2.0 implements 
access to the swap space via the file 
system for both FAT and the High 
Performance File System. The OS/2 
2.0 implementation should provide 
the benefit of a dynamically sized 
swap file combined with good 
performance. 

Continuing down the table, a maxi¬ 
mum of 240 DOS applications runs 
under OS/2 2.0. This number is 
equal to the maximum number of ap¬ 
plications. In practice, few people 
will reach the suggested limit of 32. 
OS/2 2.0 provides windowing of 
DOS applications on the PM 
desktop in all text and VGA graph¬ 
ics modes. Windows 3.0 386 en¬ 
hanced mode, however, supports 
windowing of DOS applications for 
text and CGA graphics. 

Although Windows includes a print 
spooler, its services are not available 
to DOS applications, and printing 
concurrently from DOS applications 
is not supported. Windows permits 
only one DOS application to print 
and requires that other DOS applica¬ 
tions are suspended if they attempt 
to print concurrently. 

Using a DOS print spooler (loaded 
prior to Windows) is not a viable so¬ 
lution, because printing concurrently 
from multiple DOS sessions causes 
output to become intermixed on the 
same page. Windows warns of a de¬ 
vice conflict while using the printer 
and offers a choice on how to pro¬ 
ceed. But regardless of the choice, 
the same incorrect output appears. 
OS/2 2.0 provides correct spooling 
of printer output from concurrent 
DOS applications. 

Under DOS, many specialized de¬ 
vices are supported directly from the 
application without a device driver. 
The ability to run these applications 


is under the heading “direct H/W 
access.” 

Similarly, some DOS applications 
are extremely timing-sensitive, 
mostly in the area of communica¬ 
tions applications using high data 
rates. These are supported in all envi¬ 
ronments when the application is in 
the foreground. However, in DOS, 
OS/2 1.3, Windows real mode, and 
Windows standard mode, the applica¬ 
tion is suspended while in the back¬ 
ground and cannot satisfy any 
timing constraints. 



OS/2 2.0 implements 
access to the swap space 
via the file system for 
both FAT and the High 
Performance File System. 


In 386 enhanced mode, Windows 
3.0 provides the option of setting ex¬ 
clusive mode, so a timing-sensitive 
application can be run in the fore¬ 
ground without interference due to 
time slicing. However, all other ap¬ 
plications are suspended and do not 
run while this DOS application is 
running in exclusive mode. In some 
cases, the need for exclusive mode 
can be avoided by manually adjust¬ 
ing the relative application priorities. 
The ability to dynamically manage 
priorities permits OS/2 2.0 to multi¬ 
task timing of critical applications 
both in the foreground and back¬ 
ground. 

Some DOS applications include a 
technology known as DOS extenders 
that allow the application to execute 
out of extended memory. DOS ex¬ 


tenders based on the DPMI specifica¬ 
tion are supported under all environ¬ 
ments except OS/2 1.3. 

Other extenders, including those 
based on the Virtual Control Pro¬ 
gram Interface (VCPI) specification, 
are not supported outside of DOS it¬ 
self. These types of extenders are in¬ 
consistent with the mechanisms used 
in OS/2 2.0 to protect the system or 
other applications from application 
errors. 

Most of the environments rarely con¬ 
tinue after a serious application 
error, because a failure that hangs a 
DOS application usually also hangs 
the entire system. In 386 enhanced 
mode, Windows 3.0 can sometimes 
continue after a serious application 
error, but will fail when the applica¬ 
tion has overwritten portions of 
DOS or Windows that are in the 
DOS address space. Windows usu¬ 
ally advises the user to shut down 
and restart Windows, because the er¬ 
rant DOS application may have left 
the system in an unstable state. Be¬ 
cause of the protection mechanisms 
in OS/2 2.0, a DOS application error 
should not affect anything in the sys¬ 
tem other than its own session, al¬ 
lowing OS/2 to continue after 
application errors occur. 

Therefore, when it comes to running 
DOS applications, OS/2 2.0 should 
clearly be superior to both the Win¬ 
dows 3.0 and DOS environments. 

Market Positioning 

To best understand the marketplace, 
consider the wide variety of worksta¬ 
tion environments, usage levels, and 
existing configuration needs. Then, 
look at IBM’s suggested positioning 
of the operating systems in relation 
to those needs. 

Environment: Although actual use 
of personal computers varies widely. 
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Stand-alone Workstation 

Work Group LAN 

• No LAN attachment 

• LAN-based resource sharing 

• May have asynchronous 

• Multiple work group LANs 

communications 

(via bridges) 

• Personal productivity and stand-alone 

• Non-SNA host communications 

versions of small business 

• Multi-vendor hardware and software 

departmental or special-purpose 

• Local and distributed personal 

applications 

productivity, mail, small business. 


departmental, and special-purpose 


applications 


• Server-based systems management 

Enterprise Workstation 

Enterprise LAN 

• No LAN 

• Large LAN networks 

• Controller-based connection to host 

• High-volume, high-performance 

(mid-range, mainframe) 

networks 

• Local personal productivity and 

• SNA host communications 

host applications/mail 

• Multi-vendor hardware and software 


• Work group applications, distributed 


host applications/mail 


• Host-controlled system and network 


management 


Figure 3. Workstation Environments 

it is helpful to classify personal com¬ 
puter use into the four workstation 
environments shown in Figure 3. 

There are various levels of usage for 
personal computers, which can be 
described with the following usage- 
level characteristics: 

Entry - uses personal productivity 
applications one at a time. May have 
a single asynchronous, LAN, or 
SNA communications session. 
System typically has 2 MB or less 
of memory. 

Intermediate - uses personal produc¬ 
tivity applications with expanded or 
extended memory. Utilizes “task 
switching” to switch between multi¬ 
ple applications. May have a single 
asynchronous, LAN, or SNA com¬ 
munications session. System typi¬ 
cally has 2 to 4 MB of memory. 


Advanced - uses multitasking, 
mission-critical, or complex applica¬ 
tions as well as personal productiv¬ 
ity applications. May use one or 
more simple or advanced communi¬ 
cations sessions. System typically 
has 4 to 8 MB of memory. 

Server - provides broad function, 
from print/file sharing to distrib¬ 
uted/cooperative processing. Addi¬ 
tional requirements include 
interoperability, multitasking, net¬ 
work management, and software 
distribution. 

Product Positioning: The follow¬ 
ing guidelines should help you select 
the proper operating system: 

DOS - continues as the low-end op¬ 
erating system of choice for entry 
systems, typically equipped with less 
than 2 MB of memory. DOS should 


be selected for entry usage in all 
four workstation environments. 

DOS/Windoxvs 3.0 - provides an ex¬ 
cellent extension to DOS for sys¬ 
tems containing 2 to 6 MB of 
memory. This graphical Windows 
environment will continue to satisfy 
entry-level needs in the foreseeable 
future. Given the significant invest¬ 
ment in 8088, 8086, and 286 technol¬ 
ogy, DOS/Windows can satisfy the 
investment return in the short term 
until the move is made to 32-bit 
technology. DOS/Windows should 
be selected for entry-level usage in 
all four workstation environments 
and for intermediate usage in small 
businesses in stand-alone worksta¬ 
tion and workgroup LAN 
environments. 

OS/2 1.3 (16-bit) - provides a robust 
operating system platform for sys¬ 
tems containing 2 to 6 MB of mem¬ 
ory. OS/2 1.3 should establish itself 
as the high-quality, preferred operat¬ 
ing system for users of 286, 386, or 
higher systems. In addition, OS/2 
1.3 will continue to be an SAA™ 
platform and will be made more flex¬ 
ible by packaging the Communica¬ 
tions Manager™, Database 
Manager™, and LAN functions 
(today available only in IBM’s OS/2 
Extended Edition) so they will run 
on any Intel-based hardware plat¬ 
forms using IBM or non-IBM OS/2 
Standard Edition. In the future, IBM 
intends to enhance OS/2’s Communi¬ 
cations Manager and Database Man¬ 
ager components by adding 
functions like ISDN, forward recov¬ 
ery, and access to DB2™ (remote 
unit of work gateway). OS/2 1.3 
should be selected for advanced use 
in all four workstation environments 
and for intermediate use in me¬ 
dium/large accounts in all worksta¬ 
tion environments. It should also be 
selected for servers. 
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OS/2 2.0 (32-bit) - will become the 
“Integration Platform.” Multiple 
DOS, Windows, and 16-bit OS/2 ap¬ 
plications will run better on OS/2 
2.0 than in their current environment 
for any 32-bit system (386SX, 
386DX, 486) containing 3 to 8 MB 
of memory. Communications Man¬ 
ager, Database Manager, and the 
LAN function will also be available 
on this platform. Additionally, new 
32-bit applications can be developed 
and run, leading to a fuller exploita¬ 
tion of the 32-bit hardware 
technology. 

OS/2 2.0 should be selected for inter¬ 
mediate and advanced use in all four 
workstation environments. It is a can¬ 
didate for any 386SX or better with 
at least 3 MB. It should also be used 
for servers. 

Application Migration 

Given the large number of DOS ap¬ 
plications and the emerging numbers 
of Windows applications, a key con- 



Additional productivity 
gains can be made by 
migrating 16-bit 
applications to 32-bit 
applications as time 
permits. 


sideration is how well this applica¬ 
tion base runs on OS/2 2.0. This in¬ 
cludes both continued use of 
existing applications and the option 
of using unique applications that 
may first appear under DOS or Win¬ 
dows but not OS/2. This require¬ 
ment needs to be addressed from 
two viewpoints: user and developer. 

User Perspective: The goal is for 
OS/2 2.0 to run DOS, Windows, and 
OS/2 applications better than DOS, 
Windows, or OS/2 1.3, in terms of 


usability, integrity, and performance. 
Without any need to upgrade any ap¬ 
plications, user productivity should 
increase after installing OS/2 2.0. 

Additional productivity gains can be 
made by migrating 16-bit applica¬ 
tions to 32-bit applications as time 
permits. IBM expects to make signif¬ 
icant progress towards achieving its 
stated goals in OS/2 2.0. However, 
these goals may not be fully 
achieved until a later release of 
OS/2 2.0. 

Let’s begin by looking at DOS appli¬ 
cations, and then continue with Win¬ 
dows and OS/2 applications. Here’s 
how they will operate on OS/2 2.0. 

DOS applications - support all DOS 
real-mode applications. The key 
DOS extensions for EMS, XMS, and 
DPMI services are provided by OS.2 
2.0. Applications using DOS extend¬ 
ers to run in protected mode work 
only if the extender conforms to the 
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DPMI specification. When the ex¬ 
tender does not conform, an upgrade 
to a version of the extender support¬ 
ing DPMI is required. 

Most applications run well without 
much user attention. In some cases, 
the advanced properties feature of 
the DOS environment provided by 
OS/2 2.0 can be used to reduce re¬ 
source requirements or improve per¬ 
formance. In a few cases, hardware-, 
timing-, or DOS-dependent applica¬ 
tions require advanced properties. 

A database of recommended settings 
is included with OS/2 2.0 to help 
configure applications’ advanced 
properties. The OS/2 new shell al¬ 
lows DOS applications to be started 
and managed directly. 

DOS applications running in all text 
or VGA graphics modes can appear 
in windows on the PM desktop. Con¬ 
current printing from multiple DOS 
applications is supported by the 
OS/2 2.0 spooler, unlike Windows 
3.0, which does not provide print 
spooling to DOS applications. 

Windows 2.1 and 3.0 applications - 
are supported. All necessary code is 
included with OS/2 2.0, including 
the standard Windows printer and 
plotter drivers. For other devices, the 
Windows printer or plotter drivers 
provided by the hardware manufac¬ 
turer is required. 

The goal is for Windows 3.0 applica¬ 
tions to run together with the other 
applications on the PM desktop. 
However, this goal may not be fully 
achieved until a later release, and ini¬ 
tially the Windows 3.0 applications 
may run on a separate Windows 
desktop. Windows 2.1 applications 
will always run on desktops of their 
own. Windows 3.0 requires shutting 
down Windows and restarting in real 
mode to run Windows 2.1 applica¬ 


tions. Windows and PM applications 
will communicate via the clipboard 
protocol and via the DDE protocol. 

Existing OS/2 applications - should 
perform better on OS/2 2.0 than on 
OS/2 1.3. Best of all, users can take 
advantage of new applications as 
they appear, whether they are DOS, 
Windows, 16-bit OS/2, or the new, 
more powerful OS/2 2.0 applications. 

Developer Perspective: While the 
decisions for the user are simple and 
straightforward, the decisions facing 
the developer are considerably more 
complex. Should applications be de¬ 
veloped for Windows, OS/2, or 
both? What about future applica¬ 
tions? When is development of a 32- 
bit application an appropriate choice? 

DOS applications - can be migrated 
to OS/2 2.0. Regardless of whether 
the target of the DOS port is a Win¬ 
dows or a PM application, the struc¬ 
tural design differences imposed by 
writing to a graphical user interface 
requires considerable rework in the 
structure of a DOS application. OS/2 
2.0 offers the option of porting the 
DOS application to a 16-bit full¬ 
screen application with minimal re¬ 
structuring, just as OS/2 1.3 does. 
However, given the capability of run¬ 
ning DOS applications on OS/2 2.0, 
the need for such a port is question¬ 
able unless the application needs to 
add function that would benefit di¬ 
rectly from access to more memory 
or from using features provided by 
OS/2. 

16-bit applications - will be a mar¬ 
keted for both Windows and OS/2 
2.0. That is not as much of a prob¬ 
lem as it might seem given the sup¬ 
port provided the Microsoft software 
migration kit (SMK), often referred 
to as the Windows Libraries for 
OS/2 (WLO). As described in the 
Microsoft Systems Journal , Novem¬ 


ber 1990, porting most Windows 3.0 
applications to OS/2 is simple. Most 
applications designed with the port 
maintains a single set of readable 
source code. IBM is developing its 
own new migration package with en¬ 
hancements for OS/2 2.0, both to 
continue improving performance and 
to enable missing function, like the 
palette manager. Experience with a 
recent Microsoft SMK is that the 
overall performance on OS/2 is only 
about 10 percent slower than on 
Windows, and performance is notice¬ 
ably smoother on OS/2 when multi¬ 
tasking. The goal for the IBM 
migration package is to provide bet¬ 
ter overall performance on OS/2 2.0 
than the same application running on 
Windows 3.0. 

The OS/2 2.0 device driver kit sup¬ 
ports porting Windows device driv¬ 
ers to OS/2 as easily as applications 
port through the IBM migration 
package. This makes it easy for hard¬ 
ware vendors supporting devices on 
Windows to also support these de¬ 
vices on OS/2. For vendors develop¬ 
ing OS/2-unique drivers, the device 
driver kit also has a library of rou¬ 
tines and a template OS/2 device 
driver to simplify the task. 

Because OS/2 2.0 runs Windows ap¬ 
plications directly, a natural question 
is, why bother releasing a PM ver¬ 
sion of the application? A PM ver¬ 
sion will be released because it 
provides an easy way to differentiate 
the application by taking advantage 
of the additional features of OS/2 
2.0. Examples are: 

• Support of long file names under 
the High Performance File Sys¬ 
tem and improved data integrity 

• Better integration into the OS/2 
new shell 

• Use of threads for better multitask¬ 
ing and responsiveness within the 
application 
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OS/2 is best-suited for applications: 

• With communications and 
database requirements 

• Requiring interprocess communi¬ 
cations, multitasking, semaphores, 
multithreading, or graphics 

32-bit applications - benefit from 
OS/2 2.0’s flat memory model. This 
environment does not have the prob¬ 
lems associated with 64 KB seg¬ 
ments. The 16-bit segmented 
memory model forces applications 
to write code that depends on seg¬ 
mentation and manages the virtual 
address space. Applications with 
many code and data segments or re¬ 
quiring access to very large data ob¬ 
jects are especially sensitive to 
limitations of 16-bit segmentation. 

Any discussion of the benefits of a 
32-bit architecture leads directly to 
performance. OS/2 2.0 enables ex¬ 
ploitation of the 386 and 486. The 
performance improvement clearly de¬ 
pends on what the application does 
and how the application interacts 
with the operating system. Ad¬ 
vanced capabilities such as full- 
motion video, digital sound, and 
speech and handwriting recognition 
often require complex algorithms to 
perform. 

As demonstrated in preliminary test¬ 
ing of performance-sensitive areas 
of OS/2 2.0, there should be a signif¬ 
icant benefit by using native 386 in¬ 
structions with 32-bit operands. 
Low-level functions such as string 
manipulation, 32-bit integer math, 
data movement, and pointer opera¬ 
tions should be approximately twice 
as fast as 16-bit equivalent instruc¬ 
tions. Applications written in C 
should achieve 5 to 15 percent im¬ 
provement with minor changes and 
recompilation. Simple memory man¬ 
agement changes should equate to 
an additional five percent of perfor¬ 
mance. Applications fully imple- 


16-bit OS/2 

32-bit OS/2 

Multitasking APIs 

Minor modifications 

Some redundant APIs deleted 

Signal APIs 

Combined into exception management 

Simple to change 

Exception-management APIs 

Process model becomes thread model 

Exit processing unchanged 

Pipes/queue APIs 

Unchanged 

Semaphore APIs 

New, concise semaphore model 

Simple to migrate/change 

Timer services 

Unchanged 

Memory management APIs 

New APIs to manage flat memory objects 

Simple for most applications 

File system APIs 

Unchanged (except names standardized) 

Session management APIs 

Unchanged 

Presentation Manager APIs 

Minor modifications 

Some redundant APIs deleted 

Device Driver Interface (DDI) 

Unchanged 


Figure 4. PM Application Migration from 16-bit to 32-bit OS/2 


mented to take advantage of the flat 
memory and the new unique 32-bit 
interfaces should achieve 20 to 60 
percent improvement in performance. 

The flat memory allows for the elim¬ 
ination of loading and reloading of 
segment selectors for accessing fetch 
access register “FAR” data, FAR 
calls, huge arrays, and long vari¬ 
ables. The combination of 32-bit ap¬ 
plications using the new, optimized 
32-bit APIs, like memory manage¬ 
ment and semaphores, should maxi¬ 
mize performance. An application 
showing the greatest performance 
improvements seen to date is 
REXX, for example, where, in pre¬ 
liminary testing, the preceding pro¬ 
duced a 60 percent improvement in 
performance while processing 
statements. 

A primary motivator behind the de¬ 
sign of the OS/2 2.0 APIs is portabil¬ 
ity. The flat, 32-bit, virtual address 
space is a common feature on many 


platforms and is key to portability. 

To better compete with other high- 
end workstation operating platforms 
such as UNIX®, OS/2 2.0, including 
its applications, dynamic link librar¬ 
ies, and kernel should be retargeted 
to other processors, such as the 
RISC System/6000™. Likewise, it is 
desirable that applications from 
other platforms port easily to OS/2. 
The 32-bit flat memory architecture 
in OS/2 2.0 removes one of the key 
inhibitors to a successful port. 

In support of portability, consider¬ 
able effort has also gone into mak¬ 
ing the APIs more extensible, 
removing dependencies on specific 
processor architectures, and provid¬ 
ing a meaningful and consistent nam¬ 
ing convention. Figure 4 contains a 
summary of what can be expected 
when porting an OS/2 application 
from 16-bit to 32-bit. 

Another case is creating 32-bit ver¬ 
sions of Windows applications. This 
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16-bit Windows 

32-bit Windows 

32-bit OS/2 

User APIs 

All 16-bit values become 32 bit, includ¬ 
ing message parameter and handles. Care 
is needed with window words. 

Similar changes 


Input model changes 

Message reordering 

No change 

GDI APIs 

32-bit coordinate system 

Many graphics applications affected 

16-bit coordinate system available 
(32-bit optional) 


60-plus API calls changed 

GDI to GPI change similar 


Some API calls removed 


Multitasking APIs 

All new APIs 

Similar changes 

Pipes APIs 

DOS calls turned into Windows APIs 

Similar changes into OS/2-based APIs 

Timer services 

?? 

Use OS/2-based APIs 

Memory management 

Change to flat memory 

Similar changes 

File system APIs 

DOS int 21 functions 
turned in Windows APIs 

Use OS/2-based APIs 

Session management 

Largely unchanged 

Use OS/2 PM APIs 


Figure 5. Application Migration of 16-bit Windows to 32-bit Windows or to 32-bit OS/2 


decision is more complex, because 
Microsoft has disclosed that a 32-bit 
version of Windows will be re¬ 
leased. A discussion of Windows 3.2 
is included in the next section, 
which discusses future OS/2 direc¬ 
tions. Regarding porting issues. Fig¬ 
ure 5 shows what it means to port a 
16-bit Windows application to 32- 
bit, either Windows or OS/2, broken 
down by the API groups. The infor¬ 
mation on Windows 3.2 is based on 
the information made publicly avail¬ 
able by Microsoft at the time this 
was written. 

A perception about Windows 3.2 is 
that it should be easy to move Win¬ 
dows applications to this API. A 
port to OS/2 is perceived as being 
more difficult; however, this is not 
necessarily so. Basically, the 
changes needed are similar for both 
Windows 3.2 and OS/2 2.0. 

A lot of the complexity of moving a 
Windows application to exploit the 


new 32-bit world deals with the new 
function. The rest comes with the 
new environment, changing parame¬ 
ters from 16 to 32 bits, and from seg¬ 
mented to flat memory. In many 
cases, 16-bit OS/2 PM applications 
can be converted to 32-bit with mini¬ 
mum effort. Converting 16-bit Win¬ 
dows applications to 32-bit requires 
considerable work, regardless of 
whether the target is Windows 3.2 
or OS/2. 

Within the API categories shown in 
Figure 5, the function provided by 
the Windows APIs closely matches 
OS/2 2.0 functionality. However, at 
present, the semantics of the individ¬ 
ual API calls are different. Another 
consideration is that OS/2 2.0 sup¬ 
ports mixed 16- and 32-bit applica¬ 
tions, thereby easing migration. As 
of this writing, Microsoft is offering 
Windows 3.2 support only for 32-bit 
applications. Most of the function 
promised for Windows 3.2 will be 
available on OS/2 2.0 later this year. 


Languages and Tools: IBM’s goal 
is to make OS/2 2.0 the develop¬ 
ment platform of choice for both 
OS/2 and DOS/WinJows applica¬ 
tions. This goal will be accom¬ 
plished by enabling developers to 
exploit the power of the newer, high- 
performance hardware platforms, 
which includes running multiple 
compiles for program builds and sup¬ 
port for debugging DOS and Win¬ 
dows applications. The high degree 
of system integrity provided by 
OS/2 2.0 is an additional benefit. 

The result should be better perfor¬ 
mance and throughput with higher 
productivity. 

IBM is working to ensure the avail¬ 
ability of a comprehensive set of pro¬ 
gramming tools on OS/2, both from 
IBM and independent software ven¬ 
dors (ISVs). IBM intends to provide 
a core set of 32-bit development 
tools including: 

• A 32-bit optimizing and ANSI 
conforming C compiler 
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• A configurable programming edi¬ 
tor (extensible through REXX) 

• A 32-bit PM interface debugger 

• A project-oriented workbench 
with an open architecture 

IBM is working with ISVs to pro¬ 
vide the comprehensive existing 16- 
bit OS/2 tools in 32-bit OS/2 
versions as well. The IBM tools will 
be provided with IBM service and 
support. Existing 16-bit OS/2 tools 
will continue to work on OS/2 2.0 
for developing 16-bit applications. 

No prerequisite toolkits should be 
needed for developing simple appli¬ 
cations. The necessary libraries and 
binding files are shipped with the op¬ 
erating system. The base system also 
includes the standard IBM Proce¬ 
dures Language - REXX. The future 
direction for REXX is object technol¬ 
ogy to enhance its ease-of-use and 
power. A toolkit for developing 
more complex applications will in¬ 
clude items like resource editors and 
compilers, message file creation and 
binding tools, the IPF compiler, sys¬ 
tem profilers, and on-line 
documentation. 

Future OS/2 Directions 

This section discusses the New Tech¬ 
nology (NT) kernel, database, multi- 
media, software components, LAN 
solutions, and distributed 
environments. 

NT Kernel (OS/2 3.0): Develop¬ 
ment responsibilities between IBM 
and Microsoft changed in September 
1990. Microsoft accepted lead re¬ 
sponsibility for the development of a 
new, portable kernel based on newly 
emerging technologies. This kernel 
meets Department of Defense 
B-level security standards and is cer¬ 
tified at the C2 level. New file sys¬ 
tem technologies and symmetric 
multiprocessing are also being ex¬ 


plored. The plan is to provide a fu¬ 
ture version of OS/2 built on top of 
this kernel. Microsoft has indicated 
it intends to support Windows and a 
32-bit extension of Windows as well 
as PM on this kernel. Because OS/2 
will also be supported on top of NT, 
the same capabilities will be avail¬ 
able or can be easily provided for 
OS/2 applications. Most of the re¬ 
maining function slated for Win¬ 
dows 3.2 and NT will be available 
in OS/2 2.0 later this year. 

One of the objectives of NT is to 
run on non-Intel processors, notably 
RISC processors. While DOS, Win¬ 
dows (16- and 32-bit) and OS/2 (16- 
and 32-bit) applications will be eas¬ 
ily supported by NT running on an 
Intel processor, the situation is more 
complex on RISC. The technology 
for providing DOS emulation on 
RISC is well-understood and is now 
available on the IBM RISC Sys¬ 
tem/6000™. Windows and OS/2 ap¬ 
plications that are 32-bit need to be 
recompiled with Assembler routines 
rewritten. For Windows and OS/2 
16-bit applications, the memory seg¬ 
mentation model presents a problem. 
The technology for getting these ap¬ 
plications to run well on a RISC pro¬ 
cessor, short of porting them to a 
32-bit implementation, is not under¬ 
stood today. For this reason, 32-bit 
implementations appear to be a bet¬ 
ter choice today if future portability 
across processors is a business 
consideration. 

Database: IBM is developing the 
OS/2 database to meet the industry’s 
need for scalable high performance, 
robustness, reliability, fault toler¬ 
ance, manageability, security, recov¬ 
erability, mainframe database 
access, and interoperability across 
multiple platforms. IBM will pro¬ 
vide full, 32-bit operation on OS/2 
2.0 and support client operations 
under DOS, Windows, OS/2, AIX®, 


and UNIX. Both ANSI SQL™ and 
SAA SQL compliance are goals, 
with support for application develop¬ 
ment in multiple high-level lan¬ 
guages on OS/2, AIX, and UNIX. 

APIs will be developed for use by 
applications, and front-end tools will 
be provided to monitor and control 
database operations. Work is pro¬ 
ceeding toward supporting a distrib¬ 
uted environment, including links to 
DB2 and SQL/DS™. The published 
distributed relational database archi¬ 
tecture (DRDA) “language” is de¬ 
signed so both IBM and non-IBM 
developers can produce software 
that interfaces as either a server or a 
requester to DB2 initially, with sub¬ 
sequent support on the other IBM re¬ 
lational database products. 

Multimedia: This is an important 
new area for OS/2. Development of 
multimedia products can be easier 
on OS/2 than on Windows. The ex¬ 
perience with IBM products like 
Audio Visual Connection™ and 
M-Motion has been that Windows 
implementation requires signifi¬ 
cantly more effort than OS/2. This is 
a result of better: 

• Encapsulation of system resources 
by OS/2 1.3; under Windows, the 
programmer needs to be aware of 
directly controlling the system 
resources 

• Stability of OS/2 1.3, especially 
in the area of multitasking, which 
provides improved coexistence of 
applications with less coding ef¬ 
fort. For example, items like 
“yield points” required under Win¬ 
dows are not necessary with 
OS/2 1.3 

• Graphics, such as Bezier func¬ 
tions, on OS/2 1.3 

The combination of better multitask¬ 
ing and the support for threads, 
leads to better synchronization of the 
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multiple data streams needed for 
multimedia. An example is synchro¬ 
nizing digital audio with analog 
video for a firing cannon or a talk¬ 
ing head. OS/2 2.0 “fast threads” is 
an enhancement designed to im¬ 
prove the threads performance for 
multimedia applications. In Win¬ 
dows, synchronization is left entirely 
up to the application. 

Multimedia applications frequently 
need to deal with large memory ob¬ 
jects for bit maps, audio streams, or 
even streams of bit maps. These ob¬ 
jects are much easier to manipulate 
in the flat 32-bit memory model pro¬ 
vided by OS/2 2.0. Although the 
Windows 3.0 SDK provides the 
WINMEM32 DLL, which is an inter¬ 
face for allocating 32-bit flat mem¬ 
ory from a Windows application, 
Windows remains a 16-bit seg¬ 
mented environment. Use of 
WINMEM32 leads to a mixed 16- 
or 32-bit application with the usual 
risks associated with the unpro¬ 
tected, global memory allocation 
used in Windows 3.0. As described 
in the SDK, all the complex issues 
of managing a mixed 16- or 32-bit 
application beyond memory alloca¬ 
tion basics must be addressed by as¬ 
sembly language code provided by 
the developer. Moreover, the 
WINMEM32 DLL is not part of the 
retail Windows 3.0 product. 

Object-Oriented Development: A 

significant emerging software tech¬ 
nology is the use of objects. IBM in¬ 
tends to enhance OS/2 2.0 with 
extensions to improve support for ob¬ 
ject-oriented programming lan¬ 
guages. Support of class libraries 
using an approach equivalent to dy¬ 
namic link libraries (DLLs) is under 
consideration. Presentation services 
will be enhanced with more object- 
oriented features. In addition, there 
will be further object-oriented exten¬ 
sions to the user interface. 


Patriot Partners: Looking toward 
the 21st century, a major challenge 
in the software business is to find a 
way to provide profitable software 
solutions for specialized problems. 
Patriot Partners was formed between 
IBM and Metaphor™ Computer Sys¬ 
tems Corp. to create applications 
suitable for addressing this chal¬ 
lenge. Patriot Partners’ key objec¬ 
tives are to: 

• Vastly reduce the development 
risk associated with selecting a 
specific hardware and operating 
system platform by enabling a sin¬ 
gle product to target multiple plat¬ 
forms from multiple vendors 

• Enable the introduction of new 
software technologies, like object- 
oriented programming, visual pro¬ 
gramming, multimedia, and 
expert systems 

• Provide platform-independent ob¬ 
jects needed to build applications 
in an extensible development 
environment 

• Encourage the development of ap¬ 
plications built out of reusable 
components connected by well-de¬ 
fined protocols designed for sell¬ 
ing the components and the 
application 

• Provide tools known as assem¬ 
blers and builders for combining 
components into specialized 
applications/solutions 

• Enable better application combina¬ 
tion by end users for solving spe¬ 
cific business problems using 
visual programming and the struc¬ 
ture provided by components and 
protocols 

IBM intends to make the partnership 
technology available on OS/2 and 
AIX. Metaphor will provide the tech¬ 
nology on other platforms, including 
other UNIX systems and the 
Macintosh®. 


LAN Solutions: IBM will continue 
to strengthen its position as a pro¬ 
vider of LAN solutions. This will be 
done through enhancements to cur¬ 
rent IBM products and through part¬ 
nerships and cross-licensing 
agreements like the one recently an¬ 
nounced with Novell® Inc. Potential 
LAN enhancements are in the areas 
of local and wide area networking, 
interoperability, management, and 
communications support from both 
IBM and Novell products. Examples 
are software distribution, selective 
backup/archive, transporting 
NetWare™ IPX/SPX packets across 
SNA networks, NetWare client ac¬ 
cess to Communications Manager, 
and supporting Communications 
Manager and Database Manager ac¬ 
cess to NetWare servers. 

Distributed Environments: IBM 

recognizes the increasing importance 
of heterogeneous vendor support on 
LANs and networks, and is commit¬ 
ted to helping its customers run their 
businesses with these systems. In 
May 1990, the Open Software Foun¬ 
dation™ (OSF™) announced the dis¬ 
tributed computing environment 
(DCE), a selection of technologies 
aimed at simplifying the work for 
users and application developers in 
these complex computing environ¬ 
ments. In endorsing DCE, IBM sub¬ 
sequently announced not only 
support for DCE on AIX, but also 
the intent to extend SAA to incorpo¬ 
rate key elements of DCE. As one of 
the SAA systems, OS/2 will be a 
platform for the delivery of the key 
elements of DCE. 

DCE consists of eight key technolo¬ 
gies. Of these, six are of particular 
interest for distributed environments 
including OS/2, and can be summa¬ 
rized as follows: 
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Remote Procedure Call (RPC) - 
takes care of the communications de¬ 
tails so that writing distributed appli¬ 
cations approaches the simplicity of 
applications on a single machine. 

The basic notion is that procedures 
called by an application may actu¬ 
ally be run on a computer elsewhere 
in the network. 

Distributed Naming Service - pro¬ 
vides a single naming model 
throughout the distributed environ¬ 
ment. Resources such as servers, 
files, disks, or print queues are iden¬ 
tified by name, independent of the 
physical location in the network. 

Full X.500 support is provided. 

Time Service - provides a mecha¬ 
nism for synchronizing each com¬ 
puter in the network to a recognized 
time standard. Many distributed ap¬ 
plications need a single time refer¬ 
ence to properly determine event 
sequencing and duration. 

Security Service - provides the net¬ 
work with authentication, authoriza¬ 
tion, and user account management. 
Authentication validates the identity 
of a user or service to prevent fraud¬ 
ulent requests. Authorization is the 
process of determining whether au¬ 
thenticated users should have access 
to a resource. These facilities are 
made available through a secure 


communications capability provided 
by the RPC. 

Threads Service - is a facility to sup¬ 
port concurrent programming much 
like threads in OS/2. This will be 
used by other DCE components to 
implement their services. 

Distributed File System - joins the 
file systems of the nodes in the net¬ 
work through a consistent interface 
that makes global file access as easy 
as local file access. The Distributed 
File System should provide users 
with a uniform name space, file loca¬ 
tion transparency, and high 
availability. 

Conclusion 

OS/2 2.0 will provide the features 
that our customers need. It will be 
compatible with existing DOS, Win¬ 
dows, and OS/2 applications and 
will have the performance and en¬ 
hancements provided by 32-bit appli¬ 
cations. OS/2 2.0 will provide the 
stable base for increasingly complex, 
mission-critical, and networked ap¬ 
plications. With the OS/2 2.0 new 
shell model, OS/2 2.0 will provide a 
more productive object-oriented user 
interface. 

Of course, DOS, Windows, and 
OS/2 all have a place on the worksta¬ 
tion. In this mixed environment, 


IBM will provide a simple migration 
path to preserve investment in exist¬ 
ing applications as requirements on 
the computation platform become 
more complex. 

Windows 3.0 provides a superset of 
the DOS capability, retaining the 
ability to support DOS applications 
while adding the benefits of the GUI 
provided by Windows applications. 

With OS/2 2.0, IBM intends to pro¬ 
vide a superset of the Windows capa¬ 
bility, providing support for DOS 
and Windows applications while add¬ 
ing the benefits of an advanced GUI 
(OS/2 2.0 new shell model), greater 
integrity for mission-critical applica¬ 
tions, support for complex communi¬ 
cations requirements, and support 
for both 16- and 32-bit OS/2 
applications. 

Among these three PC operating sys¬ 
tems, OS/2 2.0 with 32-bit applica¬ 
tions is the only one that in 1991 
will utilize the performance benefits 
of the 386 and 486 hardware plat¬ 
forms. Because of these additional 
benefits combined with the competi¬ 
tive price, OS/2 2.0 should quickly 
become the operating system of 
choice for personal systems in the 
1990s. 
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Comparing 
PC-DOS, OS/2, 
and AIX PS/2 - 
Part 2 

W. Craig Chambers 
IBM Corporation 
Dallas , Texas 

The technical side of PC-DOS, 

OS/2, and AIX PS/2 are examined 
in this second installment, which 
compares these three operating 
systems. 

Each of the three operating systems - 
PC-DOS (hereafter referred to as 
“DOS’'), OS/2, and AIX PS/2 - 
have different file systems. DOS 
uses the file allocation table, or 
FAT, to allocate space on a disk. 
OS/2 uses this same system for com¬ 
patibility with DOS, yet OS/2 Ver¬ 
sion 1.2 includes a new disk 
organization system called the High 
Performance File System (HPFS). 
AIX PS/2 uses a system based on 
control blocks called inodes , which 
are similar in concept to the OS/2 
HPFS organization. Each of the file 
systems is described here. 

Directory Structure 

File systems’ directory structure was 
briefly explained in Part 1. Figure 1 
shows this structure, which has a 
first-level root directory followed by 
lower-level subdirectories. 


While similar in external appear¬ 
ance, there are major differences be¬ 
tween the file systems of AIX and 
either DOS or OS/2. In DOS and 
OS/2, directories can contain entries 
for files or subdirectories, which are 
simply files containing directory 
entries. 

In FAT-based disks, each entry is 32 
bytes long. An entry contains the 
file name and an index into the file 
allocation table (Figure 2), which is 
a group of pointers to the data on 
the disk device. The directory also 
contains the date and time the file 
was created or last modified, the file 
size, and several attribute flags. 

These flags show that the file is a 
system file, read-only, hidden from 
normal directory searches, and has 
been modified since the last backup. 

Subdirectories are simply special- 
purpose data files, which can be 
read and written by both the system 
and application programs. Many util¬ 
ities are commercially available for 
manipulating system directories, per¬ 
forming functions such as alphabetiz¬ 
ing entries, sorting entries in date 
order or file size, or performing 
other specialized functions. 

Like in DOS and OS/2, AIX directo¬ 
ries are regular files. However, in 
AIX, normal programs cannot read 
or write the directories. A bit in the 
inode, shown in Figure 7, flags the 
file as a directory. The directory 



entry contains only the file name 
and its inode number. 

Disk Organization 

FAT: DOS and OS/2 can handle al¬ 
most any storage medium and for¬ 
mat if a device driver is available. 
The system needs to know the size 
of a sector and the number of sec¬ 
tors on the device. The device driver 
can handle the translations between 
logical sectors and the physical loca¬ 
tions on the device. 

In DOS and OS/2, the disk is di¬ 
vided into 512-byte physical sectors, 
which the operating system logically 
groups into clusters. Because of a 
limitation in the addressing scheme 
used, cluster size is determined by 
disk size. 

For example, on a single-sided 
floppy disk, the cluster contains only 
one 512-byte sector. In the PC XT™ 
hard disk, the cluster contains eight 
sectors totaling 4,096 bytes. On the 
PC AT® hard disk, the cluster con¬ 
tains four sectors totaling 2,048 
bytes. 

The FAT is a structure of pointers to 
the physical space, or clusters, occu¬ 
pied by a file on the disk. The FAT 
is located at the front of the disk, 
just after the boot record. 

Pointers have 12-bit values in DOS 
versions 1 and 2, but were expanded 
to 16-bit values with DOS version 3 
to support the larger disk sizes in the 
PC AT. This means that there can 
only be 64 K pointers. With large 
disk drives, this limitation means 
that a cluster, which is the unit of 
space allocation, can be large. Be¬ 
cause the number of clusters on a 
disk depends on the disk size, the 
FAT size varies with the drive 
capacity. 


Personal Systems/Issue 3, 1991 




25 


File Name 

First Cluster 

File Size 

FILE1.DAT 

124 

10,000 

FILE2.SCR 

312 

47,021 

FILE3.PIC 

57 

128,745 


Figure 2. Simplified Sample DOS-OS/2 Directory Entry 


The directory entry for each file has 
a pointer to the first FAT entry (first 
cluster) for the file. The first FAT 
entry points to the next cluster used 
by the file, and so on, until the last 
cluster is reached. The system fol¬ 
lows the chain of FAT pointers to lo¬ 
cate the rest of the data for the file. 
The FAT is also used to map free 
space on the disk. 

In the simplified directory shown in 
Figure 2, FILE1.DAT starts in clus¬ 
ter 124 and extends for 10,000 
bytes. If the cluster size is 2,048 
bytes, this file will use five clusters. 

If the disk had many files added and 
deleted, it is likely that all the clus¬ 
ters for a file will not be contiguous 
(Figure 3). Assuming that the first 
four clusters are contiguous, they 
will occupy clusters 124, 125, 126, 
and 127. The final cluster is not con¬ 
tiguous because it is located in clus¬ 
ter 131. A sample of the FAT for 
this portion of the disk is shown in 
Figure 3. 


You can see how the chain of FAT 
entries for the file F1LE1.DAT starts 
with the entry for cluster 124 and 
points to each cluster in order. The 
last cluster, 131, contains a flag hex 
FFFF, which signifies the end of the 
chain. 

Figure 3 shows the entries for an¬ 
other file, which occupies clusters 
128, 129, and 130. There is no way 
to tell if this file begins at cluster 
128, because there could be another 
FAT entry pointing to that cluster. It 
is clear, however, that the file ends 
with cluster 130, because the hex 
FFFF flag is located in that FAT 
entry. 

Figure 3 also shows how the FAT is 
used to locate free clusters when the 
system needs to allocate space to a 
new file. Clusters 133 and 134 are 
free as shown by the value of 0 in 
their FAT entries. Remember that 
clusters 0 and 1 are always used by 
the boot record and the FAT itself. 
The FAT pointer can never have ei¬ 
ther of these values as part of a valid 
chain of file allocation pointers. 


Because subdirectories are just files, 
they can also become fragmented. 
With a cluster size of 2,048 bytes 
and an entry size of 32 bytes, a clus¬ 
ter can hold only 64 entries. If a sub¬ 
directory contains more files, it 
probably will be scattered across the 
disk, causing performance degrada¬ 
tion if files are frequently used. (Re¬ 
member that the “dot” and “dot-dot” 
entries use two of these spaces in 
the first cluster.) 

As shown in Figure 4, each disk has 
two copies of the FAT. The second 
copy is for backup if the first one is 
damaged. The CHKDSK utility uses 
this copy to correct errors that may 
occur. 

Because the first two clusters are al¬ 
ways used by the boot record and 
FATs, their entries in the FAT have 
a special meaning. These entries are 
referred to as “media descriptor 
bytes,” which are used by the sys¬ 
tem to determine the type of disk 
being used and the format of the 
FAT entries. 

As previously mentioned, if a 
cluster’s entry in the FAT is not 
zero, that cluster has been allocated 
to a file. Free clusters are indicated 
by having a value of zero in their 
FAT entry. The boot record, FATs, 
and root directory are created by the 
FORMAT command. 
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Figure 3. FAT Entries for FILE1.DAT 
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Sector 0 Boot record 

Sector 1 FAT - working copy 

FAT - backup copy 
Root directory 

Data area 


Figure 4. DOS and OS/2 Disk Map (FAT) 

Originally, the FAT fit in RAM, giv¬ 
ing fast access to the entire disk. 

With large disk drives, it’s not possi¬ 
ble to keep the FAT resident, which 
can cause performance degradation. 
The system must continually move 
the head to the front of the drive to 
find the clusters used when it is read¬ 
ing or writing a fragmented file. 

The FAT system was originally de¬ 
signed for single-sided floppy disk¬ 
ettes holding 160 KB of data. While 
the FAT was once an efficient struc¬ 
ture, it is now inadequate for today’s 
high-speed, large-size fixed disks. 

The new HPFS, which was included 
as part of OS/2 1.2, is the solution. 

HPFS Disk Map: The HPFS disk 
is divided into areas called bands. A 
directory band is located near the 
center of the volume in order to min¬ 
imize head movement while locating 
files. There are three fixed control 
structures in the HPFS: BootBlock, 
SuperBlock, and SpareBlock. 

The BootBlock is larger than the 
simple boot record in the FAT sys¬ 
tem. It is larger because the boot pro¬ 
gram is more complex to handle 
than the HPFS organization until the 
full system is loaded. 

The SuperBlock contains 32-bit 
pointers to the major system areas 


on the disk including the root direc¬ 
tory, a map of bad sectors, a free 
space map, and other system infor¬ 
mation. It is modified by system 
maintenance utilities only. 

The SpareBlock contains other sys¬ 
tem information and is changed as 
the system runs. 

The rest of the disk is divided into 8 
MB data areas or bands, each of 
which has its own free space bit 
map. In these bit maps, each sector 
in the band is mapped by one bit, so 
it is possible to allocate space by sec¬ 
tor rather than the larger cluster 
scheme used in the FAT system. Bit 
maps for two bands are adjacent, 
and access is faster because head 
movement is minimized when files 
are allocated in adjacent bands. 

Data bands repeat as often as neces¬ 
sary to fill the disk. A 32 MB disk, 
for example, would have four data 
bands. As shown in Figure 5, it is 
possible to allocate up to 16 MB of 
contiguous space to a file organized 
this way. One of the centrally lo¬ 
cated data bands stores the 
directories. 

Every file or directory on an HPFS 
volume is associated with a structure 
called an /node. The fnode occupies 
one sector and contains data about 
the file, including: 

• The first 15 characters of the file 
name 

• Extended attributes if they will fit 

• A pointer to additional extended 
attributes 

• Pointers to the data 

• Access history 

For performance reasons, the fnode 
is stored as close to its file as 
possible. 


The FAT system considers a file to 
be a collection of clusters on the 
disk. The HPFS system looks at a 
file as a collection of runs, or contig¬ 
uous sectors, of data on the disk. 
Therefore, instead of mapping each 
cluster occupied by the file, the 
fnode contains a pointer to the start 
of a run and a size or run length 
field. 

The fnode can point to eight runs of 
data, each of which can be up to 16 
MB long. This organization allows 
small files and contiguous files to be 
described by a single fnode. 

If a file is too large or too frag¬ 
mented to be described by a single 
fnode, then the fnode becomes the 
root of a B+ tree of pointers. In 
other words, the fnode points to 
eight other sectors, called allocation 
sectors. These sectors contain the ac¬ 
tual pointers to the data, allowing a 
file to contain many sector runs. 

Each allocation sector can point to 
40 runs. 

If this is still insufficient, intermedi¬ 
ate levels can be added to the tree, 
greatly increasing the potential num¬ 
ber of runs. Each intermediate level 
can hold 60 pointers to allocation 
sectors. 

The SuperBlock points to the fnode 
for the root directory. Like in the 
FAT system, subdirectories are 
reached through pointers in their par¬ 
ent directories. Initially, directories 
are allocated four contiguous sec¬ 
tors. Subdirectories are located in 
the directory band if there is room. 
Otherwise, they are located wher¬ 
ever there is free space. 

Because HPFS supports long file 
names, there is no way to calculate 
how many entries will fit into a di¬ 
rectory sector. There is always at 
least one entry in a directory sector; 
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Sectors 0-15 

BootBlock - boot code 

1 sector 

SuperBlock 

1 sector 

SpareBlock 

Data band 1 



8 MB data area 




Free space bit map for band 1 


Free space bit map for band 2 

Data band 2 



8 MB data area 



Data band 3 



8 MB data area 




Free space bit map for band 3 


Figure 5. HPFS Drive Layout 


if files have short names, there can 
be many entries. If too many files 
are to be stored in the 2 KB direc¬ 
tory block, a new 2 KB group of sec¬ 
tors is added to the tree structure. 

Directories contain a field with the 
length of the file name, the file 
name itself, date and time stamps, 
and other control information. This 
information may be the directory 
entry length or a pointer into the B+ 
tree structure. 

File names are stored in the direc¬ 
tory in alphabetical order. Therefore, 
directory searches are generally 
faster than in the FAT system be¬ 
cause it is not necessary to search 
the entire directory to locate a file. 
When the first file later in the alpha¬ 
betical sequence is reached, the sys¬ 
tem knows that the file does not 
exist and stops looking for it. 

If you convert to HPFS and do not 
change the file name size, about 
65,000 files can be listed in a three- 
level directory tree. This means that 
in three disk accesses, you can lo¬ 
cate a file or prove that it does not 
exist. The same directory size under 
the FAT system would take more 
than 4,000 disk accesses to prove 
that the file did not exist. 

However, there is a downside. While 
locating a file is quite efficient, it 
can take a long time to add a new 
file to the directory or to rename an 
existing file. A new name must be 
added at the proper location in the 
B+ tree structure. The entire struc¬ 
ture may be reorganized if the direc¬ 
tory block is full and a new level 
needs to be created to make space 
for the file. 

Partitions: There is a more funda¬ 
mental difference between the DOS 
and OS/2 file systems and the AIX 
file system. In DOS and OS/2, each 


disk device has a unique logical iden¬ 
tifier assigned to it. For example, the 
first floppy disk drive is always 
known as drive A:, the first fixed- 
disk as C:, and each drive is as¬ 
signed the next available letter as its 
ID as it is located by the system dur¬ 
ing the boot process. 

As described earlier, each logical 
drive has a self-contained directory 
structure. It is independent of all 
other drives in the system. Valid 
disk names, or identifiers, are the let¬ 
ters A through Z, limiting DOS and 
OS/2 to a maximum of 26 disk de¬ 
vices. New drives cannot be added 
without rebooting the system. 

With DOS and OS/2, fixed disks can 
be partitioned into multiple smaller 
logical drives. Each of these smaller 
partitions receives its own unique 
drive identifier. For example, if an 
accident, like the corruption of the 
FAT or directory, destroys the struc¬ 
ture of a logical drive, it will not be 
necessary to rebuild and reload the 


entire fixed disk. Rather, only the af¬ 
fected partition would need to be re¬ 
built. 

Under OS/2, it is possible to inter¬ 
mix both FAT and HPFS logical 
drives in the various partitions on 
the fixed disk. If compatibility with 
DOS is desired, the HPFS partitions 
should be the last partitions on the 
disk. These partitions will not be rec¬ 
ognized by DOS, and the higher 
drives’ ID letter will be different 
when OS/2 is running. This process 
could be very confusing. 

AIX Disk Structure 

In AIX, the disk is organized differ¬ 
ently than the FAT-based organiza¬ 
tion of DOS and OS/2. Directories 
contain only a file’s name and a 
pointer to a structure called an 
inode. All of the information about 
the file, including allocated space, 
date and time stamps, and so forth, 
is contained in the inode. The inode 
is similar in concept to the HPFS 
fnode. 
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Block 0 
Block 1 
Block 2 


Block n 
Block n+1 

End of file system 


Unused by file system (boot record) 

superblock 

ilist 


Data blocks 


Figure 6. AIX File System Map 


Minidisks: In AIX, all disks form a 
single logical structure, which is di¬ 
vided into minidisks. The AIX sys¬ 
tem can support up to 128 
minidisks, with up to 32 minidisks 
on any physical disk drive. 

The AIX file system is called a 
mountable file system. A mount 
point is an empty directory in the 
file system, which means that a new 
disk may be added to the logical file 
structure at any time. This is signifi¬ 
cantly different than DOS and OS/2. 

Each time the AIX PS/2 system is 
started, it checks to ensure that the 
file system structure is intact. If prob¬ 
lems are found, the system tries to 
repair the damage, although it is not 
always successful. This is why the 
shutdown command must be exe¬ 
cuted before the system is turned off. 

It is sometimes necessary to refor¬ 
mat the fixed disk when installing a 
new version of the system. Refor¬ 
matting would take advantage of a 
new feature or just ensure that the 
disk has no remaining files from the 
previous system. With DOS and 
OS/2, only the C: partition needs to 
be affected by a reformatting, leav¬ 
ing the user data on the other logical 
drives unaffected. With AIX PS/2, it 
may be necessary to unload the en¬ 


tire file system if the previous mini¬ 
disk allocations did not leave suffi¬ 
cient room for the new system. 

While several minidisks are created 
when the AIX system is installed, it 
is often necessary to create addi¬ 
tional minidisks. Space can be re¬ 
served for this purpose during 
installation, or an additional fixed 
disk may be added to the system. 

The minidisk commands can be used 
to create one or more additional 
minidisks from this free space. 

The AIX disk is allocated by 4,096- 
byte logical blocks, each made up of 
eight, 512-byte physical blocks. A 
map of the file system resembles the 
diagram in Figure 6. 

AIX Disk Organization: Block 0 
contains the boot record, but it is not 
used by AIX PS/2. A separate boot¬ 
able partition, which actually boots 
the system, is created on the hard 
disk. 

The superblock tracks the file sys¬ 
tem size and name, the number of 
blocks reserved for inodes, and the 
free block list. While the system is 
running, the superblock is kept in 
memory. Before the system can be 
turned off, this data must be written 
to the disk. AIX systems require a 


special shutdown command to be is¬ 
sued before the system is turned off. 
(The OS/2 system has the same re¬ 
quirement if the HPFS file system is 
used.) 

The ilist contains structures mapping 
a file to the physical blocks on the 
disk, much like the FAT does in 
DOS and OS/2 systems. Like the 
FAT, the size of this area depends 
on the file system size. Each struc¬ 
ture, which is 64 bytes long, is 
called an inode. There is an inode 
for each file. Inodes are numbered 
sequentially from 0 to the maximum 
that the file system can hold and are 
indexed by this number. Index 2 gen¬ 
erally is the root directory. 

Inodes contain information about the 
file they refer to, such as: 

• File mode 

• File type 

• File length 

• Owner and group ID numbers 

• Date and time stamp 

• Number of links 

• Data blocks physical location 

Each inode contains 13, four-byte ad¬ 
dresses, as shown in Figure 7. The 
first 10 addresses point to data 
blocks in the file. 

If the file is larger than can fit in 
these 10 blocks, indirect block point¬ 
ers are used. These are blocks 
pointed to by the inode that contain 
pointers to the file’s data blocks. 

The number of data blocks that can 
be pointed to by the indirect block is 
dependent on the disk block size, 
which ranges from 128 bytes on 
diskettes to 512 bytes on fixed disks. 

Even larger files may need to use 
block 12 that points to a second 
level of indirect pointers. Block 13 
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points to a third level of indirect 
pointers for very large files. 

The system keeps track of unused in¬ 
odes created when a file is deleted, 
so they can be reused. The super¬ 
block contains an array of free in¬ 
odes, a count of free inodes, and a 
count of the total number of inodes 
in the system. 

The last part of the file system is the 
data area. It contains the data files, 
the indirect index blocks for large 
files, and the free blocks. 

The file system also maintains a list 
of free data area blocks in a free 
block list, which is a linked list of 


pointer blocks. These blocks are 
used for data files, indirect index 
pointers, and so forth, as needed. 

The superblock contains pointers 
and counters to maintain this list. 

Each free block pointer contains 
pointers to up to 50 free blocks, as 
well as the link pointers to the next 
free block pointer in the chain. 
Blocks are added or removed from 
this chain as needed to track the free 
blocks in the file system. 

AIX File Types: There are four file 
types in the AIX system: directory, 
ordinary, special (character, block, 
FIFO, and sockets), and symbolic 
links (which contain pointers to 
other files). 


Directory files are, as the name im¬ 
plies, subdirectories containing lists 
of filenames and associated inodes. 
Ordinary files are regular data and 
program files. Special files are used 
to run the system. These may not 
exist in the file system, because they 
are really pointers to specific device 
drivers. Finally, symbolic links are 
files containing pointers to other 
files. These pointers enable a user to 
give a short, meaningful nickame to 
a file. 

Special Directories: The AIX sys¬ 
tem uses certain directories for spe¬ 
cial functions. The /bin directory 
stores many user commands. All 
user passwords are kept in the 
/etc/passwd file. The /usr directory 
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contains subdirectories associated 
with print spooling, mail, utility com¬ 
mands, and others. 

Security has been mentioned briefly. 
The /usr/adm/sulog file logs all user 
attempts to issue the su or switch 
user (superuser) command. Because 
this command gives users system ad¬ 
ministrator capabilities, all attempted 
uses of this command are logged, in¬ 
cluding the name of the user, date 
and time, terminal used, and so forth. 

Of course, there are many more spe¬ 
cial directories in an A1X system. 
This topic was only mentioned to in¬ 
troduce the concept of special re¬ 
served directories. DOS has no 
reserved directories, and OS/2 has 
just a few. For example, OS/2 Stan¬ 
dard Edition has just one, \OS2 and 
its related subdirectories. These di¬ 
rectories contain all of its code ex¬ 
cept the loader and kernel, which are 
in the root directory. 

Installation 

DOS: As you would expect, DOS is 
the easiest of the three systems to in¬ 
stall. DOS 4.00 is shipped on two 
diskettes. Experienced users can in¬ 
stall DOS by copying the files to a 
directory on the hard disk and then 
running the SYS command, which 
copies the hidden kernel files to the 
target disk’s root directory. Later re¬ 
leases include the SELECT com¬ 
mand that displays a few screens of 
questions, allowing new users to 
specify how the system will be con¬ 
figured. 

OS/2: This operating system is 
more difficult to install because it is 
substantially larger than DOS. It is 
packed as compressed files on eight 
high-capacity diskettes for Standard 
Edition version 1.2. It is necessary 
to use the installation diskette be¬ 
cause the files are compressed and 


there are so many files whose func¬ 
tions are undocumented. 

The installation diskette is booted 
and loads a restricted version of the 
OS/2 system. Several screens are dis¬ 
played, allowing users to tailor the 
system to their requirements. The in¬ 
stallation program then creates sev¬ 
eral subdirectories into which the 
uncompressed files from the remain¬ 
ing seven diskettes are copied. 

Version 1.3 adds additional flexibil¬ 
ity to the installation process. There 
is an additional menu that lets users 
select the components to be in¬ 
stalled. This allows users with lim¬ 
ited free disk space to eliminate 
system functions not needed, such as 
the tutorial and online 
documentation. 

The installation process is not too 
complicated for Standard Edition, 
but it is more difficult for OS/2 Ex¬ 
tended Edition. OS/2 Extended Edi¬ 
tion has a Communications Manager 
and a Database Manager with sepa¬ 
rate installation menus. 

AIX: The AIX system is also quite 
large and is shipped on 19 high-den- 
sity diskettes for version 1.2. Several 
blank high-density diskettes are 
needed, because at least three of the 
diskettes must be copied during in¬ 
stallation. More diskettes may be re¬ 
quired if system maintenance is 
installed. 

Like OS/2, an installation diskette is 
first booted. Three of the distribu¬ 
tion diskettes are used for output, 
and need to be copied to other disk¬ 
ettes. From a menu, users can format 
and copy the distribution diskettes 
written to during installation, thus 
eliminating the need for changing 
original diskettes. 


The system is then rebooted, and the 
installation process begins. AIX re¬ 
quires considerably more informa¬ 
tion for installation than either DOS 
or OS/2. 

Some installation questions will sur¬ 
prise former DOS users. For exam¬ 
ple, with AIX there is a requirement 
to enter your time zone, and whether 
or not you are on daylight savings 
time. Even your machine needs to 
be named. (The name is used if your 
system is on a network. Time zone 
information converts time stamps 
from other systems to your local 
time.) These questions are not diffi¬ 
cult to answer. 

AIX also has special machine re¬ 
quirements. If you are using a PS/2 
with an enhanced small device inter¬ 
face (ESDI) drive, you may get a 
message indicating that the disk con¬ 
troller ROM needs to be upgraded. 

If one appears, there is a no-cost en¬ 
gineering change (EC) that your 
customer engineer will install for 
you. 

During installation, the fixed disk is 
divided into several minidisks, 
which are then formatted into file 
systems. The installation process cre¬ 
ates the root, user, temporary, and 
local file systems, a virtual memory 
paging space, and a dump file. The 
sizes for these minidisks may be 
specified instead of using the system 
defaults. You can also reserve some 
disk space to use later for new 
minidisks. The distribution files are 
then copied to the hard disk. 

With both DOS and OS/2, there is 
nothing in the installation process 
that cannot later be changed easily. 
Changes can be made by simply edit¬ 
ing the configuration file, 
CONFIG.SYS, which is located in 
the root directory. With AIX, how¬ 
ever, the file system space is allo- 
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cated to various system functions 
and minidisks. If this is not done cor¬ 
rectly, it may be necessary to rein¬ 
stall the entire system. 

Programming Considerations 

The Intel 808X family of microcom¬ 
puters is interrupt-driven. In other 
words, when one of a list of events 
occurs, the processor interrupts what 
it is doing and jumps to a new sec¬ 
tion of code. The various events that 
can cause interrupts are assigned a 
unique number. The address of the 
code handling that function is stored 
at the beginning of system memory 
in the interrupt vector table. The 
code address for each interrupt is the 
interrupt number times four, which 
is the size of an address pointer in 
the table. 

For example, when a key is pressed, 
the CPU is interrupted by the key¬ 
board interface hardware. The CPU 
must save its status at the time of 
the interrupt and branch to the in¬ 
structions that handle the data being 
sent by the keyboard. The CPU must 
then reload its saved status and re¬ 
turn to the instructions it was pro¬ 
cessing before the key was pressed. 
The CPU can be interrupted by ei¬ 
ther hardware or software through 
with a special interrupt (INT) 
instruction. 

Because DOS is a single-tasking sys¬ 
tem, programs assume they own the 
entire computer. DOS was designed 
around the system interrupt capabil¬ 
ity. When a program wants DOS to 
perform a function, it does not call 
DOS directly. Rather, the program 
executes a software interrupt instruc¬ 
tion. DOS uses interrupts 20H 
through 26H. 

Programs often change system inter¬ 
rupt vectors to point to their own 
code. As a result of this change, pro- 
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Figure 8. DOS, OS/2, and AIX Handles 


grams can perform simple multitask¬ 
ing, extend the functions provided 
by DOS, and so forth. For example, 
the typical pop-up program changes 
the keyboard interrupt vector to 
point to itself. The program activates 
itself upon detecting its hot-key com¬ 
bination. Other keys are passed to 
the original DOS keyboard code. 

Because OS/2 and AIX PS/2 are 
multitasking systems, they cannot op¬ 
erate in this manner. If one program 
was allowed to take over a hardware 
interrupt in a multitasking system, 
the other programs or the system it¬ 
self would probably fail, thereby 
risking data loss or corruption. For 
this reason, neither OS/2 or AIX 
PS/2 allow programs direct access to 
the interrupt vector table. 

Regular programs are not allowed to 
execute software interrupts or to 
change shared memory without sys¬ 
tem control. A call-based interface is 
used instead of the software inter¬ 
rupt interface used by DOS. The rou¬ 
tine that is called can check the 
validity of the request before passing 
it to the operating system for 
processing. 

In OS/2, programs can intercept data 
from the keyboard or other devices 
under system control by using a spe¬ 
cial program called a “monitor.” The 
system gets the data from the device 
and passes it to the monitor for pro¬ 
cessing. Then it passes the changed 
data through the normal system 


code, eliminating the need for pro¬ 
grams to intercept the hardware 
interrupts. 

When porting applications to either 
OS/2 or AIX PS/2 from DOS, all 
system calls must be recoded. The 
interrupt instructions must be 
changed to calls. If a high-level lan¬ 
guage is used, the compiler will 
make these changes. If Assembler or 
low-level C calls are used, the pro¬ 
gram changes could be extensive. 

In all three systems - DOS, OS/2, 
and AIX - several handles are as¬ 
signed when a program is started 
(Figure 8). 

It is common practice in AIX pro¬ 
grams to close handles 3 through 20 
during program initialization. This 
should not be done in DOS and is 
not recommended in OS/2 as some 
of these handles may have been 
opened by dynamic link routines. 

AIX has one major advantage for 
programmers - a flat address space. 
The Intel microprocessors used in 
DOS all have “segmented” memory. 
This means the largest contiguous 
amount of memory that can be ad¬ 
dressed is 64 KB. To maintain com¬ 
patibility with DOS and the 80286 
microprocessor, OS/2 continues this 
segmented approach to memory 
management. 

Beginning with version 2, OS/2 
adopts the flat memory addressing 
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scheme used by AIX. This is a tre¬ 
mendous advantage for program¬ 
mers who are working either with 
large programs or large amounts of 
data. With this addressing scheme, 
programmers no longer have to keep 
track of which 64 KB segment con¬ 
tains the code or data being used. 

The flat address space eliminates the 
need for the large number of mem¬ 
ory models used by languages like 
C. All programmers benefit from 
this change. 

System Calls: To a programmer, a 
system’s power is proportional to 
the number of function calls it pro¬ 
vides. IBM technical reference manu¬ 
als list 99 system calls for DOS, 265 
for the OS/2 kernel, and 550 for the 
Presentation Manager, and 66 for 
AIX PS/2. (Note: The AIX number 


looks low, but the AIX system calls 
look like C verbs and are difficult to 
count.) 

Multitasking 

DOS: There is no documented 
multitasking support in DOS. How¬ 
ever, it is possible for a program to 
terminate without releasing its mem¬ 
ory. A DOS program can give the 
appearance of multitasking by taking 
over system interrupts and terminat¬ 
ing while keeping its memory. 

For example, if a DOS program 
takes over the keyboard interrupt, it 
can activate itself, or pop up, when a 
user presses a specific hot key. 

While this is really not multitasking, 
it does give that appearance to the 
user. 


DOS programs also can take over 
the timer interrupt, which occurs 
many times a second. This gives the 
program the opportunity to execute a 
small amount of code before passing 
control to the original interrupt han¬ 
dler. This is a dangerous type of 
multitasking. There is no system con¬ 
trol over how the CPU time is allo¬ 
cated or over the number of 
programs that take over a particular 
interrupt. 

As discussed previously, DOS real 
mode programs assume they are the 
only program running in the system. 
Therefore, they are free to use any 
memory or hardware in the system. 

If other programs are running, there 
could be total havoc, as each pro¬ 
gram overlays the memory of an¬ 
other, writes to the same file, or 
sends data to the printer. If one of 
these programs should crash, it will 
probably bring down the entire sys¬ 
tem, causing loss of data when other 
programs are stopped. 

To the standard definition of multi¬ 
tasking, which is the ability to run 
multiple programs simultaneously, 
let’s add the phrase “under system 
control.” The new definition for a 
multitasking system is “a system 
that allows multiple programs to exe¬ 
cute simultaneously under system 
control.” 

Several programs add multitasking 
capability to DOS. These include 
Microsoft Windows Version 3 and 
Desqview. On the 80386 and later 
processors, these programs take ad¬ 
vantage of the virtual 8086 mode to 
isolate and protect each DOS 
program. 

OS/2: A time-sliced, priority-based, 
pre-emptive scheduler is used in 
OS/2. In fact, OS/2 has many multi¬ 
tasking capabilities that are found on 
large mainframe systems. This 
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means that an OS/2 system can run 
more than one program at a time, 
and the system controls these pro¬ 
grams. There is no chance that one 
of these programs will take over the 
entire system. As will be covered 
later, OS/2 has greater flexibility in 
multitasking than the AIX PS/2 sys¬ 
tem. 

The unit of resource allocation or 
ownership in both OS/2 and AIX is 
the “process." Program, task, and 
process are often used 
interchangeably. 

By default, each process (or task) 
has the keyboard, display screen, 
and some memory allocated to it. It 
is possible to start a background pro¬ 
cess that does not always have ac¬ 
cess to the screen and keyboard. 

Each process usually has other re¬ 
sources allocated such as data files. 

A process should be thought of as a 
copy of a program loaded into sys¬ 
tem memory plus the resources used 
by that program. 

Resources are allocated to a process. 
The CPU is allocated to a thread. If 
a process is thought of as a complete 
program, then a thread is equivalent 
to a function within that program. 
Each process has at least one thread. 
The thread is really just a stack area, 
an entry in a system table containing 
the thread’s ID and status, and a 
pointer to the next instruction to be 
executed by the CPU for that thread. 
A thread can concurrently execute 
with other threads within the same 
program or process. 

If a process needs to do more than 
one activity at a time, it can create 
another independent process to per¬ 
form the second activity. For exam¬ 
ple, if a system has two 
communication ports, it may be de¬ 
sirable to start a second process to 
handle the second port. In this case. 


these would be completely indepen¬ 
dent tasks in the system. Each pro¬ 
cess would own one port, and the 
code executed by each of these pro¬ 
cesses would be an independently 
scheduled thread. 

The new process is created with the 
DosExecPgm system call. The sys¬ 
tem loads and executes the specified 
program as either a child process or 
as a completely independent process. 



In fact, OS/2 has many 
multitasking capabilities 
that are found on large 
mainframe systems. 

There are times, however, when a 
program needs to do more than one 
activity at a time, but does not want 
to create an entirely independent pro¬ 
cess. For example, a person is using 
a word processor. The program is 
loading a large document file for up¬ 
dating by the user. The program 
may start reading the document. It 
may then stop reading long enough 
to show the first screen full of data 
before continuing to read the rest of 
the file into its buffers. 

This sequence could be done in 
DOS by counting the lines of text in 
the document as they are being read. 
When a full screen’s worth of lines 
have been read, that screen of text is 
displayed before the rest of the file 
is read. 

In OS/2, there is a better way to do 
this. As previously stated, programs 
are divided into threads of execu¬ 
tion. The typical program has just 


one thread. In this sequence, two 
threads are needed: one to read the 
document file and another to display 
the text. 

The thread reading the file sets a 
flag when enough data has been 
read to fill the screen. The second 
thread will then begin to display the 
document while the first thread con¬ 
tinues reading the remaining data. 
OS/2 provides a special flag, called 
a semaphore, just for this purpose. 
Semaphores, which are a form of 
interprocess communication or syn¬ 
chronization, are discussed in the 
section titled “Semaphores.” 

If the user scrolls ahead in the file, 
the display thread can check the 
buffer. If enough data has been read, 
the thread can display the next 
screen of text even though more 
data remains to be read. The result is 
to simultaneously read and display 
data, which makes the system seem 
more responsive to the user. If the 
user then decided to check the spell¬ 
ing of a document, the program 
could use an additional thread to per¬ 
form the spell check while the user 
is editing the document. 

The system can create a new thread 
faster than it can create a new pro¬ 
cess. This is because the system 
doesn’t have to perform any re¬ 
source allocation. The thread has 
less status information associated 
with it; therefore, the system can 
switch between threads faster than it 
can switch between processes. Each 
thread shares memory with all other 
threads in the same process, which 
makes it easy for them to communi¬ 
cate with each other. This makes 
threads a high-performance multi¬ 
tasking mechanism. Generally speak¬ 
ing, processes are the way the CPU 
is shared between applications, and 
threads are the way the CPU is 
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shared within a single application 
program. 

AIX: OS/2’s multitasking capabili¬ 
ties were described as being similar 
to a mainframe system. AIX PS/2, 
being based on UNIX and very sim¬ 
ilar to the System/370 version, is 
very close to a mainframe system 
with all the capabilities that implies. 

In AIX, multitasking is limited to 
running multiple processes. AIX 
does not have the concept of 
threads. While this allows for multi¬ 
ple programs to execute concur¬ 
rently, it reduces the ease of 
achieving multitasking within a sin¬ 
gle program, thereby complicating 
the task facing application 
programmers. 

In AIX PS/2, the fork and exec func¬ 
tions are used to start a new process. 
Unlike in OS/2, a new program file 
is not loaded into memory. Instead, 
a second copy of the parent program 
is made in memory. Both the child 
and parent process begin executing 
with the instruction following the 
fork call. It is up to the two pro¬ 
cesses to test their process IDs, de¬ 
cide whether they are parent or 
child, and branch accordingly. The 
child will start its new process with 
the exec function call. 

AIX has one handy function that is 
missing from OS/2. The ‘‘kill’" com¬ 
mand immediately terminates the 
specified process. 

In the last OS/2 example, there was 
a single process with two threads 
reading and displaying data simulta¬ 
neously. To do this without threads 
would be more difficult. In both 
OS/2 and AIX, all resources are allo¬ 
cated to a process, including system 
memory. Using one process to read 
data into a memory buffer, and a sec¬ 
ond process to display the data from 


that buffer, forces the programmer 
to find a way to share that part of 
memory between the two processes. 
Shared memory would be used to do 
this. This is discussed next as one 
means of interprocess 
communication. 

Interprocess 

Communication - DOS and 
OS/2 

DOS, like OS/2 and AIX PS/2, can 
“pipe’’ or pass output from one pro¬ 
gram to another as its input as they 
execute sequentially. This section is 
about how processes can communi¬ 
cate as they execute simultaneously. 

Because OS/2 is a multitasking sys¬ 
tem, there are several ways for its 
processes to communicate. These 
range from simple to complex. The 
following discussion looks at these 
methods in order of increasing 
complexity. 

Pipes: Used on the command line, 
pipes are the most common way to 
pass data between different pro¬ 
grams. Pipes tell the system to take 
the output from one program and re¬ 
direct, or pipe it to another program 
as that program’s input as is done by 
DOS. With pipes, a FIFO stream of 
data is sent in one direction between 
any processes in the system. Pipes 
are slower than shared memory be¬ 
cause the data is first passed to the 
system by the sending program, and 
then passed from the system to the 
receiving program. They are also 
limited to a 64 KB data segment 
size. If two-way communication is 
needed, then two pipes must be 
used; one for reading and one for 
writing. Piped data is kept in mem¬ 
ory, it is not written to disk. 

OS/2 added support for named pipes 
in version 1.1. Named pipes allows 
a pipe to send data between unre¬ 


lated processes, including those on 
different OS/2 systems if connected 
on a network. 

The pipe looks like a regular file, 
but with special naming conven¬ 
tions. The system takes care of mov¬ 
ing the data to the receiving process 
on the receiving system. OS/2 Ex¬ 
tended Edition must be used if a 
named pipe is used between differ¬ 
ent systems. 

Named pipes can be used to send 
and receive either bytes of data or 
messages. Therefore, with a single 
call, a process can receive a com¬ 
plete message from another process. 

Shared Memory: Using shared 
memory is the fastest way to ex¬ 
change data between processes. It is 
necessary for each process to issue 
the proper system commands to 
have access to the shared memory 
area. Shared memory also has the 
greatest flexibility for the applica¬ 
tions programmer, because the data 
in the shared memory can be ar¬ 
ranged any way the programmer de¬ 
sires. Also, with shared memory, 
data can be randomly accessed. 

Queues: These are the final form of 
interprocess communication. This is 
the most versatile form, because 
data can be any length and can be 
read in both a FIFO or LIFO (last 
in, first out) order, or by message pri¬ 
ority. Queues are useful when one 
process collects data from several 
other processes; for example, a data 
collection program. 

Data Files: These can also be used 
as interprocess communication. 

While slower than the other meth¬ 
ods, files provide a recovery capabil¬ 
ity in case the system should crash. 
They also allow for large quantities 
of data to be shared. 
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Semaphores: These were briefly 
mentioned earlier. Semaphores syn¬ 
chronize different threads or pro¬ 
cesses. One thread waits to perform 
some function until it is notified by 
a semaphore that there is work to be 
done or that a needed resource is 
available. While waiting for the 
semaphore, the system puts the 
thread to sleep. OS/2 semaphores 
are binary, which means they are ei¬ 
ther set or clear. This is clearly a 
form of interprocess communication. 
Because only a ready or not-ready 
signal is being communicated, it’s 
not a method of sharing data. 

OS/2 has two types of semaphores - 
system and RAM. System sema¬ 
phores are maintained by the system 
and can be used by any process in it. 
They follow a naming convention 
similar to regular files. A RAM 
semaphore is not maintained by the 
system. It is simply a global variable 
within a program. Therefore, it can 
only be used by threads within a sin¬ 
gle program. 

Interprocess 
Communication - AIX 

In AIX, there is the same support for 
pipes as in OS/2 plus some addi¬ 
tional capabilities. Data can be redi¬ 
rected on the command line using 
similar command syntax, but with 
the tee command, data can be redi¬ 
rected to two places simultaneously. 
In other words, AIX PS/2 not only 
can pass results of one program to 
another, but it can also display or 
print the same information or route 
it to a third program. 

AIX pipes can only be used between 
related processes; that is, between 
parent and child processes or be¬ 
tween child processes with the same 
parent process. As in OS/2, pipes are 
FIFO data streams. 


While AIX PS/2 does not have a 
named-pipe function, it does have a 
special file type called FIFO. Its 
functions are similar to the named 
pipe in OS/2. Because it is a file, it 
is stored on disk. FIFOs do not re¬ 
quire that processes using them are 
related; in fact, the print spooler is 
implemented this way. 

Both message queues and sema¬ 
phores are similar to their equivalent 
OS/2 functions. Message queues are 
used to share data, and semaphores 
are used to synchronize processes. 

In AIX, the entire process is put to 
sleep if the semaphore it is waiting 
for is unavailable. This differs from 
OS/2 where the CPU is dispatched 
at the thread level. In OS/2, sema¬ 
phores are referenced by name. In 
AIX PS/2, they are referenced by an 
ID number. 

In OS/2, a semaphore is either set or 
clear. In AIX PS/2, a semaphore is 
really a counter and can have many 
values. For example, if a resource 
can be used by several processes at 
one time, the semaphore could be a 
count of the number of active users. 
Instead of testing to see if the sema¬ 
phore is just set or clear as is done 
in OS/2, the AIX program tests the 
semaphore for the actual count of 
users of the resource and branches 
based on the result. 

A group of semaphores that are cre¬ 
ated or manipulated with a single 
cell are referred to as semaphore 
sets. These sets are provided by AIX 
PS/2. 

AIX PS/2 has a shared memory func¬ 
tion similar to the one in OS/2. As 
with OS/2, this function provides the 
fastest way to share data, because it 
is not moved among the different 
processes using it. 


Signals: Another form of inter¬ 
process communication is the signal. 
Usually used to communicate the oc¬ 
currence of an external event, an ex¬ 
ample of a signal is a user pressing a 
key to abort the program (Ctrl-Break 
in DOS and OS/2, Ctrl-C in AIX). 
One process also can send a signal 
to another process. If a process 
wants to handle a specific signal, it 
must establish a routine to do so. 
Otherwise, the system will take de¬ 
fault action for the signal, which is 
usually to terminate the program. 

Device Drivers 

A device driver is a program that in¬ 
terfaces between operating system 
calls and a particular hardware de¬ 
vice. Device drivers are designed to 
shield the system kernel from han¬ 
dling device operation details. 

For example, because DOS supports 
floppy disk drives, fixed disk drives, 
the screen, keyboard, and a printer, 
it includes specific routines in the 
kernel that provide the programming 
interface to these devices. However, 
if a programmer knows the details 
of the device function calls, a clev¬ 
erly written program could directly 
address a specific device, thereby by¬ 
passing the built-in device driver. 

If a new type of hardware device is 
added to the system that is not sup¬ 
ported by the built-in device drivers, 
the appropriate device driver must 
be added to the system. This device 
driver is usually supplied by the 
hardware vendor. 

OS/2 includes the same device driv¬ 
ers found in DOS as part of the ker¬ 
nel. Because the kernel contains 
drivers for most standard hardware, 
on DOS and OS/2 systems the 
VDISK.SYS driver is the most com¬ 
monly added device driver. 
VDISK.SYS allocates and organizes 
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a portion of system memory as a log¬ 
ical disk drive, giving programs fast 
access to small amount of often-used 
data. 

In both DOS and OS/2 systems, de¬ 
vice drivers can be located any¬ 
where in the file system. They can 
be included in the system by adding 
a DEVICE=driver file name line to 
the CONFIG.SYS file. This file is 
read during system initialization and 
identifies device drivers to be 
loaded. If a driver specified in the 
CONFIG.SYS file works for one of 
the default system devices, the stan¬ 
dard driver in the kernel is not used. 

OS/2 device drivers are considerably 
more complicated than their DOS 
counterparts. The complication re¬ 
sults from OS/2’s multitasking sup¬ 
port. This support often results in 
more than one outstanding request. 
Because OS/2 operates in both real 
mode and protected mode, device 
drivers must be bimodal. In other 
words, they handle both physical ad¬ 
dresses for buffers when operating 
in real mode and virtual addresses 
when in protected mode. 

OS/2 drivers also must be able to re¬ 
move themselves on demand, which 
is done to conserve memory if multi¬ 
ple drivers for the same device are 
loaded. The previous driver can re¬ 
lease its memory because its func¬ 
tions are handled by the second 
driver. 

With these special OS/2 considera¬ 
tions, OS/2 device drivers must be 
re-entrant. This is a more difficult 
way to write a program. OS/2 has 
special functions used by device 
drivers called Device Driver Help¬ 
ers, or DevHlps, which make this an 
easier process. Beginning with OS/2 
Version 1.1, special interdriver com¬ 
munication (IDC) entry points were 
also established. 


The AIX system is considerably dif¬ 
ferent because programs never di¬ 
rectly address a device. The AIX 
device driver is the only code that 
talks directly to a device. There is a 
device driver for every device in the 
system. Device drivers must be 
linked into the system using the Id 
command. To add another device 
driver, the system must be generated 
(linked) and then restarted. 

Device Monitors 

Some DOS applications permanently 
load into memory and then activate 
themselves when an operator enters 
a certain “hot key” sequence. Re¬ 
ferred to as a “pop-up” or terminate 
and stay resident (TSR), this type of 
program and has become quite 
popular. Borland’s SideKick is an 
example of this type program. Unfor¬ 
tunately, this type program takes 
over a key system resource - the 
keyboard (and perhaps the timer) - 
without the system having any con¬ 
trol over it. 


As these programs proliferated, their 
combined memory requirements be¬ 
came significant. There was often a 
conflict between their hot keys, 
timer interrupt usage, and so forth. 
Standards have been proposed to 
control how these programs operate, 
but they are not universally fol¬ 
lowed. The optimum solution is 
OS/2’s device monitor capability. A 
device monitor is a type of program 
inserted into the layered system 
structure at the device-driver level. 

Device drivers are difficult to write 
because they work closely with the 
hardware, yet device monitors are 
easy to write. The device driver con¬ 
tinues to control the actual hardware 
device. A monitor signals that it 
wants to look at incoming data from 
a specific device. The device driver 
passes each data item to the monitor 
after it has been read from the de¬ 
vice, but before it is passed onto the 
system. Monitors can look at output 
data, too. 


Command 

Function 

CALL 

Calls another batch file from within a batch file 

ECHO 

Displays or suppresses echo of commands as batch file exe¬ 
cutes; or echoes this command 

FOR 

Repetitively executes a command 

GOTO 

Branches to a new location in the batch file 

IF 

Tests a condition and branches if true 

PAUSE 

Stops execution of batch file, displays user prompt, and waits 
for a keystroke 

REM 

Defines a comment line 


Figure 9. DOS and OS/2 Batch File Commands 


Command 

Function 

ENDLOCAL 

Restores the drive, directory, and environment variables in effect 
when the previous SETLOCAL command was issued 

EXTPROC 

Defines an external batch file processor 

SETLOCAL 

Saves the drive, directory, and environment variables currently 
in effect to restore later with an ENDLOCAL command 


Figure 10. OS/2 Batch File Commands 
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This device driver function isolates 
the monitor from the hardware 
while including it in the data path. 
Multiple monitors can work with 
data from the same device if 
chained together by the device 
driver. Data is then passed to each 
of the monitors in turn. A single 
monitor can register with several de¬ 
vice drivers and act as a path be¬ 
tween them. These programs could 
be print spoolers, keyboard en¬ 
hancers, or other utilities that filter 
data independently of other 
programs. 

OS/2 includes a special monitor dis¬ 
patcher to control device monitor ex¬ 
ecution. Because the monitors 
operate at such a low level in the 
system architecture, they must be de¬ 
signed carefully not to adversely af¬ 
fect system performance. 

Because the monitor is controlled 
by the device driver, the device 
driver must include the necessary 
support code for this function. The 
standard OS/2 device drivers for the 
keyboard, mouse, and printer have 
the necessary support code. How¬ 
ever, the COMx and SCREENS 
drivers do not have this support for 
the screen and serial devices. 

Shell Programs, Batch Files, 
and REXX 

Figure 9 lists the special batch file 
commands available with DOS or in 
the DOS compatibility session of 
OS/2. 

When not using REXX while in pro¬ 
tected mode, OS/2 adds three addi¬ 
tional commands to those available 
under DOS. Figure 10 lists these 
commands. 

The only special variables available 
to DOS and OS/2 batch files are %0 
through %9. These variables were 


Name 

Purpose 

BEEP 

Sounds the system speaker 

CALL 

Allows internal routines (labels), built-in functions, and external 
functions to be called as subroutines 

CHARIN 

Reads characters in from an input stream 

CHAROUT 

Writes characters to an output stream 

CHARS 

Returns the number of characters remaining in an input stream 

COMPARE 

Returns the result of the comparison of two strings 

COPIES 

Returns concatenated copies of a string 

C2D 

Converts a character to decimal 

C2X 

Converts a character to hexadecimal 

DATATYPE 

Returns the result of checking the data type 

DATE 

Returns the date set on your PC 

DELSTR 

Deletes a substring as a character unit 

DELWORD 

Deletes a substring as a word unit 

DIRECTORY 

Returns the name of the current directory 

DO 

Groups instructions and optionally runs them repetitively 

D2C 

Converts decimal to character 

D2X 

Converts decimal to hexadecimal 

EXIT 

Leaves or ends a program unconditionally 

FILESPEC 

Returns a selected file specification of either drive path or name 

FORMAT 

Rounds and formats a number 

IF 

Allows conditional processing of functions, instructions, and 

OS/2 commands 

LASTPOS 

Returns the position of the last occurrence of a string 

LENGTH 

Returns the length of a string 

LINEIN 

Reads a line from an iinput stream 

LINEOUT 

Writes a line to an output stream 

PARSE 

Assigns data from various sources to one or more variables 

PULL 

Reads a string from the head of the external REXX data queue 

RETURN 

Returns control, and possibly a result from a REXX program or 
internal routine, to its starting point 

SAY 

Writes to the default output stream 

TIME 

Returns the local time set on the system in the format hh:mm:ss 
or in the format specified in the option 

TRACE 

Selects or sets the tracing of system events 


Figure 11. Selected RKXX Commands 
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Command 

Function 

for 

Executes a command repetitively 

if 

Tests a condition and takes action as appropriate; action can be complex group of commands; if the tests are 
false, and an else branch is provided, the else commands are executed 

while 

Executes group of commands while tested condition is true 

until 

Executes group of commands until condition is true 

(list) 

Executes command in the list in a subshell 

{ list; ) 

Executes command in the list in the current shell 


Returns a 0 exit value; null 

.file 

Reads and executes the commands in file in the current shell 

break 

Exits from a for, while, or until loop 

continue 

Resumes execution of a loop 

echo 

Displays command line 

eval 

Reads arguments as input to the shell and execute the resulting command 

exec 

Executes specified command in place of this shell in this process 

exit 

Leaves shell and sets a return code if specified 

export 

Marks specified names of environment parameters for passing to subsequently executed shells 

hash 

Remembers location in the search path for each specified name 

newgrp 

Changes primary group identification 

pwd 

Displays current directory 

read 

Reads a line from standard input and assigns each word to the specified variables 

readonly 

Makes specified variables readonly so they cannot be reset 

return 

Exits a function and passes a return code if specified 

set 

Sets flags controlling script execution 

setxvers 

Sets experimental version prefix to the specified string 

shift 

Moves command line left logically by decrementing the index of each parameter 

test 

Evaluates conditional expression 

times 

Displays accumulated user and system times for processes run from shell 

trap 

Runs specified command when system sends specified signal to shell 

type 

Indicates how shell would interpret specified command name 

ulimit 

Sets or queries size limits 

umask 

Sets user file creation mask to specified value 

unset 

Removes corresponding variable from the environment for each name specified 

wait 

Waits for specified child process to end 


Figure 12. Shell Script Commands 
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$$ 

Process ID 

$# 

Number of parameters on command line 

$* 

Text string with all command line parameters 

$? 

Last return code from executing program 

$! 

Process ID of last process started in background 

$- 

String with execution flags currently set in shell 

$1 ...$9 

Parameters passed on the command line 


Figure 13. Variables Passed into Shell Scripts 


passed to the batch file on the com¬ 
mand line. If more than nine were 
passed, the SHIFT command must 
be used to address the additional 
variables. Environment variables 
can also be specified as replaceable 
parameters. 

REXX has several other major capa¬ 
bilities. A program can use it to exe¬ 
cute a REXX program or to receive 
and execute REXX commands. Pro¬ 
grams written in other languages 
can be invoked as REXX functions, 
and programs can read and write 
REXX variables. In other words, 
REXX can control multiple pro¬ 
grams running in OS/2 and can pass 
data and commands between them 
by controlling the OS/2 system. Fig¬ 
ure 11 lists some REXX commands. 

The AIX PS/2 system has similar 
power to REXX. Its command lists 
are called shell scripts. Like REXX, 
shell scripts can get input from the 
user, which can then be used to con¬ 
trol the script program’s execution 
path. Shell scripts are so powerful 
that it is not uncommon for applica¬ 
tions to be prototyped as shell 
scripts before the actual code is writ¬ 
ten. There is even a commercial 
bookkeeping package available that 
is written as a shell script. 

File names are not used to tell the 
system a file can be executed. After 
creating the shell script, the chmod 


command must be used to mark the 
script executable before it can be 
run. 

AIX PS/2 has many shell script 
commands. Each shell has a differ¬ 
ent set of commands and syntax. 

The Bourne shell is the default for 
AIX PS/2. The commands for the 
Bourne shell are listed in Figure 12. 

AIX PS/2 makes extensive use of 
the environment to support shell 
scripts. Figure 13 contains a list of 
the standard environment variables 
passed by the Bourne shell to shell 
script programs. 

Summary 

Part 2 has presented a more techni¬ 
cal description of the DOS, OS/2, 
and AIX PS/2 operating systems to 
help you understand how these sys¬ 
tems are designed. The program¬ 
ming capabilities and installation 
procedures have also been discussed. 

We can conclude that DOS is the 
operating system of choice for users 
with little technical knowledge and 
with limited programming require¬ 
ments. Microsoft Windows Version 
3 gives the appearance of the Pre¬ 
sentation Manager with a limited 
form of multitasking, which gives 
you time to wait for OS/2 Version 2. 

It is relatively easy to migrate to 
OS/2 from DOS. Programs do not 


have to be converted to OS/2 func¬ 
tions immediately, because the DOS 
compatibility session allows most 
existing DOS programs to continue 
being used. Microsoft Windows can 
still be run in the DOS compatibil¬ 
ity session, which will make migra¬ 
tion to Presentation Manager very 
easy. OS/2 2.0 will run Windows ap¬ 
plications directly, thereby preserv¬ 
ing your software investment. 

As the most powerful and complex 
of the three systems, AIX PS/2 is, 
in my opinion, the ideal system to 
use in a network. It is designed for 
multiple users who share the same 
computer or who need compatibility 
or connectivity with UNIX systems. 
AIX has more functions at the com¬ 
mand interface than either DOS or 
OS/2. If you have a requirement for 
multiple users to connect to the 
same system unit, then AIX PS/2 is 
the perfect system. 
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Using Dual 
Displays with 
OS/2 

Larry Pollis 
IBM Corporation 
Dallas, Texas 

Traditional support for dual dis¬ 
plays cannot be achieved on PS/2 
systems. This article shows what 
can be done under OS/2 and ex¬ 
plains the differences in behavior 
of dual displays on PS/2 systems 
and its predecessors. 

With the release of OS/2 Version 
1.2, support for dual displays has 
been provided by the operating sys¬ 
tem on the PS/2 line of computers. 
This support has been implemented 
within relatively narrow constraints, 
which are carefully defined in this ar¬ 
ticle to avoid any misunderstandings. 

Prior to PS/2 systems, dual display 
support could be set up by installing 
a monochrome display adapter and a 
color display adapter in an IBM PC, 
XT, or AT system (or compatible). 
Because of how PCs address video 
RAM, dual display support can only 
be obtained with one adapter of each 
type. The color adapter could be 
CGA, EGA, VGA, or the Profes¬ 
sional Graphics Adapter. 

Applications had to be written with 
dual display capability in mind to uti¬ 
lize both displays. Three applica¬ 
tions that include this support are 
Lotus 1-2-3™, AutoCAD®, and 
CodeView™. Both Lotus 1-2-3 and 
AutoCAD used one screen for the 
text-based information and the other 
for displaying graphics (a chart with 
Lotus 1-2-3 and a drawing in 
AutoCAD). CodeView used one 
screen to display the program source 
code, breakpoints, variables, and a 


command area; the other screen (usu¬ 
ally the color monitor) showed the 
application as it executes under the 
control of the debugger (CodeView). 

OS/2 Support 

Hardware Requirements: The plat¬ 
form supporting the Dual Display 
feature under OS/2 is quite specific. 
The PS/2 line of computers (Micro 
Channel models 8550 through 8580) 
includes a VGA display adapter on 
the system board. To implement 
dual displays, an 8514/A display 
adapter or an Image Adapter/A must 
be installed on the system in addi¬ 
tion to the system VGA interface. 

The following PS/2 displays may be 
used on the system board connector: 
8503, 8506, 8507, and 8508 mono¬ 
chrome displays, and the 8512, 

8513, 8514, and 8515 color displays. 
An 8507 monochrome monitor, 

8514 color display or the 8515 color 
display must be attached to the 
8514/A or the Image Adapter/A. 

The 6091 color display must be at¬ 
tached to the Image Adapter with 
6091 cable option only. 

Software Configuration: The Dual 
Display feature was introduced with 
OS/2 Version 1.2. The option for 
dual display support appears during 
the initial installation of either OS/2 
Standard Edition or Extended Edi¬ 
tion. The system actually detects the 
presence of the 8514/A and asks if 
there are displays attached to both 
adapters. If “yes” is the answer, the 
system unpacks, automatically in¬ 
stalls the necessary drivers, and then 
updates CONFIG.SYS with the 
proper statements. 

If the 8514/A is installed later, it is 
necessary to manually unpack and 
copy the correct files to the hard 
disk. To activate both displays, the 
CONFIG.SYS file must be changed 
and the system rebooted. This proce¬ 


dure is clearly stated in Operating 
System/2 Standard Edition Version 
1.3 Using Advanced Features 
(91F8505) pages 24 through 28, and 
in Operating System/2 Extended Edi¬ 
tion Version 1.3 User's Guide Vol¬ 
ume 1: Base Operation System 
(C1F0289) chapter 2, pages 9 
through 11. 

8514/A Adapter Installation: 

Figure 1 shows the procedure to fol¬ 
low after installing the 8514/A 
Adapter. In the instructions, VGA is 
the installed device, and the files in¬ 
stalled are IBMVGA.DLL and 
BVHVGA.DLL. The 
IBMVGA.DLL file was copied to 
DISPLAY.DLL. To install an 
8514/A (with memory, in this case), 
two additional files - 
IBMBGA.DLL and 
BVH8514A.DLL - must be un¬ 
packed and copied from the distribu¬ 
tion disks to the \OS2\DLL 
subdirectory. 

OS/2 Dual Display Definition 

Operating System Support: OS/2 
allows for 16 simultaneous sessions, 
or screen groups, to share a PS/2’s 
resources. OS/2 does this intelli¬ 
gently and impartially by allocating 
time, memory, and access to devices 
that make up the system. It’s impor¬ 
tant to understand that the PM shell 
operates in one of these screen 
groups and can allow OS/2 to man¬ 
age multiple processes within that 
shell. This, in effect, shares that sin¬ 
gle screen group even further. PM 
uses windows to subdivide the 
screen group, providing access to 
the display for various processes. 

OS/2 offers limited support to users 
with dual displays. The 8514/A 
adapter and the 8514 monitor are re¬ 
served for the PM screen group. All 
other screen groups are directed to 
the system board VGA and its at- 
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tached monitor. These include all 
full-screen applications, OS/2 Full 
Screen Command sessions, and the 
DOS compatibility box. 

Limitations: When a system has 
been set up with two displays, and 
the system is first turned on, the PM 
screen group appears on the display 
attached to the 8514/A. The display 
attached to the VGA port will proba¬ 
bly be blank, and remains so until an 
application requiring a screen group 
of its own is started. Once a full¬ 
screen application has the input 
focus (keyboard, mouse, and cursor), 
the PM display becomes static and 
will not be updated. The applica¬ 
tions continue to run. Using 
ALT-ESC (or CTRL-ESC) causes 
the system to switch back to the PM 
display, thereby freezing the full¬ 
screen display and allowing the dis¬ 
play to be updated. 

Only one of the displays can be ac¬ 
tive at any given time. The inactive 
monitor continues to display the 
image (or data) that was on the 
screen when the focus was removed. 
That screen cannot be updated until 
the focus has been returned. The op¬ 
erating system and the PS/2 design 
do not allow updates to both moni¬ 
tors simultaneously. 

CodeView! 

What about CodeView? It seems 
that whenever dual displays are men¬ 
tioned, CodeView comes to mind 
and vice versa. This relationship 
comes from CodeView’s history 
under the DOS and IBM PC environ¬ 
ments. CodeView was described ear¬ 
lier as one of the early applications 
supporting and benefiting from dual 
displays. Those who’ve used 
CodeView on that platform may re¬ 
member that both displays are up¬ 
dated in realtime. 


Find the diskette with the 1BMBGA.DLL and BVH8514/A files, insert it 
into the A: drive, and enter: 

UNPACK A:IBMBGA.DL@ C:\0S2\DLL 
UNPACK A:BVH8514/A.DL@ C:\0S2\DLL 

Remove the OS/2 disk from drive A: and replace it with the installation 
diskette. Reboot the system, press ESC at the IBM logo, and enter: 

COPY C:\0S2\DLL\IBMBGA.DLL C:\0S2\DLL\DISPLAY.DLL 

Edit the CONFIG.SYS to change the lines that read: 

DEVINFO-SCR. VGA. C:\0S2WI0TBL.DCP 
SET VIDEO_DEVICES=VIO_IBMVGA 
SET VIO_IBMVGA=DEVICE(BVHVGA) 

to: 

DEVINFO-SCR. BGA, C:\0S2WI0TBL.DCP 

SET VIDEO_DEVICES=VIO_.IBMVGA, VI0_IBM8514A 

SET VIO_IBMVGA=DEVICE(BVHVGA) 

SET VI0_IBM8514A=DEVICE(BVH8514A) 

Save the file and close the editor. Turn off the system and place the 
8514/A adapter into the slot reserved for it. Turn on the system again and 
boot from the reference disk to install the .ADF file and to configure the 
system’s CMOS memory. Remove the reference disk and reboot the sys¬ 
tem again. The system now displays the PM screen on the 8514 monitor 
and any VIO full-screen program on the VGA display. 


Figure 1. Procedure after Installing 8514/A Adapter 


When CodeView was used with a 
single monitor in either DOS or 
OS/2, the display would “flip” or 
“swap” as each statement (in single- 
step mode) was executed. This was 
done so the output screen could be 
updated and viewed after each state¬ 
ment. It also slowed the debugging 
process. CodeView contains an op¬ 
tion that turns off screen swapping, 
letting the debugging process oper¬ 
ate faster. If the output screen must 
be viewed, press F4. Under DOS, 
you can toggle between the output 
screen and CodeView. When debug¬ 
ging in OS/2, the F4 key shows the 
output screen for a (user modifiable) 
period of time and then returns to 
the CodeView display. Using two 


monitors with DOS and the PC elim¬ 
inated the need for screen swapping 
and the time delay encountered 
while repainting the screen. With 
OS/2, displays still “flip.” 

Because of the constraints imposed 
by OS/2 and the PS/2, CodeView 
cannot use two displays as it could 
under DOS on a PC. At best, using 
two displays allows the programmer 
to continue seeing the PM desktop 
while viewing the source code 
within the debugger. Using both dis¬ 
plays applies only if a PM applica¬ 
tion is being debugged. If a 
full-screen application is being exe¬ 
cuted under CodeView, screen flip¬ 
ping is done on the VGA display 
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with a single monitor in the same 
way as under DOS. 

Further, an application cannot use 
both displays simultaneously. For ex¬ 
ample, CodeView running under 
DOS on a PC can control where and 
when it writes to video RAM, even 
if the video RAM starts at two differ¬ 
ent addresses. CodeView can use the 
monochrome monitor for itself and 
direct output of the new application 
under its control to another monitor, 
which can happen in realtime or dy¬ 
namically. A loop of code can write 
a character to video RAM for each 
iteration of the loop. The character 
is visible as soon as the character 
code is placed in memory. This be¬ 
havior cannot be obtained with OS/2. 

Caution! When using CodeView to 
debug a PM application, it’s not un¬ 
usual to get an overwhelming urge 
to use ALT-ESC to switch to the 
PM session to see your application’s 
windows and output. Users com¬ 
monly forget that they’re in a debug¬ 
ging session and switch to PM to 
access another PM application. Do 
not do this! Doing so locks the sys¬ 
tem, and the only way out is to turn 
the system off and on again. 

This situation happens while debug¬ 
ging, because at least one instruction 
has executed. CodeView is trying to 
exert control over an operating sys¬ 
tem that, by definition, does not 
want to be controlled. OS/2 is a 
multitasking operating system that 
doesn’t allow any application to 
upset or affect another. CodeView 
“tricks” OS/2 into letting it control 
the application being debugged. 

OS/2 allows this, but in a narrowly 
defined way. If ALT-ESC is used to 
switch to PM, CodeView and OS/2 
become deadlocked. 

The inverse of switching from 
CodeView to PM is also not al¬ 


lowed. During debugging, the appli¬ 
cation eventually needs user interac¬ 
tion. At this time, the system focuses 
on the PM session. (You can check 
this by moving the mouse. If the 
mouse pointer on the PM screen 
moves, it has the focus.) Do not at¬ 
tempt to switch to CodeView . If you 
do, the system locks up, and turning 
the system off, and then back on is 
the only way out. The only way to 
get back to CodeView is to termi¬ 
nate the application or encounter a 
breakpoint. If the application is 
being single-stepped and input is re¬ 
quired, the focus will remain with 
the application until the requirement 
has been satisfied. 



With dual displays, users 
can focus on the PM 
screen earlier than 
normal when switching 
back to the PM session. 


Benefits: The advantage of dual dis¬ 
plays under OS/2 is the comfort of 
seeing the Presentation Manager 
screen group while working in a full¬ 
screen session or in the DOS compat¬ 
ibility box. With dual displays, users 
can focus on the PM screen earlier 
than normal when switching back to 
the PM session. The screen update 
process repaints the various win¬ 
dows while users focus on what 
they’re going to do next. In the case 
of CodeView and debugging, it is 
easier to follow the new application 
code when the application output is 
constantly visible. 

XGA Support 

Where does the new XGA Adapter 
fit into the PS/2 or OS/2 platform? 


Support for Extended Graphics 
Array hardware is the same as for 
the 8514/A with a few additional fea¬ 
tures. Anti-aliased text offers easier 
readability and displayed text has a 
better appearance. With XGA, there 
is a choice of resolutions and colors, 
depending on the amount of display 
memory available. For a better un¬ 
derstanding of the XGA support 
with OS/2 V.1.3, read pages 27 and 
28 in Operating System/2 Standard 
Edition Version 1.3 Using Advanced 
Features (91F8505). 

Summary 

PS/2 hardware cannot dynamically 
update its attached displays in combi¬ 
nation with the system board VGA 
and either the 8514/A adapter or the 
Image Adapter/A. OS/2, starting 
with Version 1.2, selects the high- 
resolution display adapter for the 
PM session and switches to the pla¬ 
nar VGA for all full-screen sessions. 
An OS/2 application cannot direct 
text or graphics to a particular dis¬ 
play in any way. Because Codeview 
is a full-screen application, it dis¬ 
plays on the VGA-attached display. 

If CodeView is used to debug an¬ 
other full-screen application, it 
“screen flips” both CodeView’s and 
the application’s output on the VGA 
display. When debugging a PM ap¬ 
plication, the “screen flip” still takes 
place between the two displays. Be¬ 
cause OS/2 has to update the PM dis¬ 
play, single-step debugging is slow. 
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Twenty-five years ago, computers 
had not yet assumed a place in 
the office. By the early 1980s, a 
revolution in computer technology 
changed how people interact with 
them. 

In the mid 1960s, people interacted 
with computers by delivering piles 
of data to keypunch operators who 
entered them onto punch cards. The 
trays of cards went to a computer op¬ 
erator who ran the jobs. Checks 
were issued, reports printed, and re¬ 
cords updated at amazing speeds, 
compared to the manual systems 
used previously. 

Computers were important to all 
sorts of organizations, but they had 
not yet assumed a place in the of¬ 
fice. Instead, they were locked up in 
special, environmentally controlled 
rooms, known as “glass houses,” 
and were tended to by specially 
trained people who were developing 
a language of their own to describe 
their interactions with the computer. 

In the 1970s, smaller computers not 
requiring special environments 
began to appear in the workplace. 

The video display terminal and 
friendlier human interfaces allowed 
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users to store large amounts of text- 
based records. The computer be¬ 
came an electronic filing cabinet 
instead of merely a calculator. 

Still, the possibilities for manipulat¬ 
ing information stored to meet spe¬ 
cific users’ needs was extremely 
limited. By the early ’80s, a revolu¬ 
tion in computer technology in¬ 
creased densities and decreased 
prices of storage, and memory dra¬ 
matically. This changed how people 
interacted with computers by placing 
very powerful workstations in the 
individual’s workplace and home. 

Today, a personal computer puts 
more power on your desk than re¬ 
sided in the “glass house” of the 
1960s. Yet, this power costs less 
than one percent of the 19608- 
vintage system. More importantly, 
all that power lets you choose how 
you want to interact with the com¬ 
puter. Powerful new applications let 
users store and retrieve information 
in ways tailored to meet their needs. 
Now, spreadsheet programs let indi¬ 
viduals prepare reports and charts in 


minutes. In the 1960s, programmers 
spent hours creating reports of this 
complexity. The personal computer, 
once the office status symbol, has be¬ 
come commonplace. 

One of the first things that people 
noticed as personal computers en¬ 
tered the workplace was that they 
seldom work in total isolation. Early 
personal computer users developed 
their own slow but highly reliable 
networks for interchanging data and 
programs. In most organizations it 
was called “Sneakernet.” The floppy 
disk and its descendants let people 
walk around the office with an amaz¬ 
ing amount of information written 
on something that weighs only a few 
ounces. Everyone learned how to 
use COPYDISK and COPYFILE al¬ 
most immediately. But Sneakernet, 
reliable as it was as a data transport 
mechanism, was too slow and de¬ 
pended too heavily on human rela¬ 
tionships. Besides, even the most 
resourceful user still needed access 
to information and resources that 
were best handled by the mainframe. 
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Personal computers were made to 
emulate the terminals they recently 
displaced in the office. When used 
as an emulator, much of the personal 
computer’s power is unused. Interac¬ 
tion through the mainframe to other 
PC users was possible, but it was 
only slightly better than Sneakemet. 
These users needed a way to share 
resources in a peer-to-peer relation¬ 
ship. Local area networks (LANs) 
were designed to meet these new 
needs. 

The requirements for a good LAN 
are simple. The network must: 

• Enhance the power of the devices 
attached to it 

• Be invisible to the user of the at¬ 
tached device 

• Have a standard implementation 
supported by a wide variety of 
equipment manufacturers 

• Be flexible in its physical 
installation 

• Be highly reliable and easily 
managed 

Enhanced Power 

LANs enhance the power of the per¬ 
sonal computer by giving you access 
to shared resources such as high¬ 
speed printers and data storage de¬ 
vices. The LAN is a high-speed 
expressway to the information you 
need, no matter where that informa¬ 
tion resides. Through bridges and 
gateways, LANs let you reach out to 
information anywhere in your organi¬ 
zation - to co-workers in the next de¬ 
partment, the branch office in 
Chicago, or the manufacturing plant 
in England - without ever leaving 
your desk. Moreover, the LAN is 
usually faster than dialing a long-dis¬ 
tance phone number and making the 
connection. When the already power¬ 
ful personal computer is attached to 
a LAN, all of your organization’s re¬ 
sources are at your fingertips. 


In addition to sharing the power of 
other network devices, the LAN lets 
you share information with other net¬ 
work users. The network pulls your 
organization together no matter how 
large or geographically scattered it 
may be. You can now communicate 
in moments with colleagues half a 
world away. And, because the com¬ 
munication is personalized - a note 
to colleague in England whom you 
have never met, perhaps - the net¬ 
work helps create new working 
relationships. 

Clearly, the power of the network 
goes beyond the interactions of ma¬ 
chines and the sharing of informa¬ 
tion and resources. The network can 
help bind your organization together 
by its ability to connect people and 
information. 

Invisibility to the User 

In a short time, we’ve become very 
matter-of-fact about the average 
person’s ability to use computers 
and networks. Almost everyone uses 
an automatic teller machine (ATM) 
occasionally to conduct his or her fi¬ 
nancial affairs. Using the ATM has 
become almost intuitive, thanks to 
careful human factors engineering. If 
LANs are to succeed in their mis¬ 
sion of connecting people to informa¬ 
tion and to other people, their use 
must be so intuitive as to be invisi¬ 
ble to the user. 

Network users must be able to find 
any information without impairing 
the access of others and without 
knowing anything about where infor¬ 
mation is stored. For example, an in¬ 
surance claims examiner should 
need nothing more than the 
policyholder’s name and policy num¬ 
ber to gather electronically a com¬ 
plete history of the policyholder’s 
coverage and previous claims. The 
examiner should not have to know 


that the coverage information resides 
on the mainframe in the San Fran¬ 
cisco and the claims information 
came from five regional claims cen¬ 
ters. LANs provide the connectivity 
to make access to such information 
possible. Systems analysts and pro¬ 
grammers everywhere are working 
to make that access as simple as 
your ATM transactions. 

Standards and Variety 

If the LAN is to be the highway 
through your organization, it will 
work only if everyone has access to 
it, and if all who use it agree upon a 
set of rules. If LAN access is limited 
or the rules are unclear, communica¬ 
tion is inhibited rather than 
enhanced. 

The computer industry works to¬ 
gether to develop LAN standards - 
rules that permit LANs to operate 
and to facilitate communications 
among devices designed by different 
manufacturers. These standards must 
be strict enough to ensure that a 
LAN will function reliably, yet flexi¬ 
ble enough so all vendors can pro¬ 
vide equipment that can operate as 
peers on the network. The Institute 
of Electrical and Electronics Engi¬ 
neers (IEEE) 802 family of LAN 
standards is widely accepted by both 
the computer industry and its 
customers. The predominance of 
token ring networks and Ethernets is 
a testimony to how well these com¬ 
mittees have done their work. Now 
the standards are defining how these 
two networks - and others - should 
communicate with each other. Many 
organizations have both token ring 
and Ethernet networks. For some 
time, this coexistence was a barrier 
to building an organization-wide, 
peer-to-peer network. Now those bar¬ 
riers are coming down as bridges 
and routers are being developed to 
link these networks together. 


Personal Systems/Issue 3, 1991 


45 


As networks grow larger and new ap¬ 
plications require higher data rates, 
the standards organizations are seek¬ 
ing ways to accommodate these de¬ 
mands with minimal disruption. For 
example, the IEEE 802.5 Token 
Ring Network Standard Committee 
initially developed the standard for a 
4 Mbps network. As demand in¬ 
creased, the committee developed a 
16 Mbps standard that allowed 4 
Mbps token ring users to migrate 
easily to this more powerful imple¬ 
mentation of the token ring standard. 
Now, the ANSI X3T.9 committee is 
developing the Fiber Distributed 
Data Interface (FDDI), a 100 Mbps 
standard employing a token-passing 
protocol that should integrate easily 
into organizations presently using 
token ring networks. 

Physical Flexibility 

LANs are being installed in almost 
every conceivable workplace. Al¬ 
though the industry is developing 
wireless networks, large-scale imple¬ 
mentation of this concept appears to 
be some years away. For now, 

LANs depend on cables to link de¬ 
vices in the workplace. Industry stan¬ 
dards activities are helping both the 
computer manufacturer and the user. 
The Telecommunications Industry of 
America (TIA) is about to publish a 
standard for commercial building 
wiring. That standard, in conjunction 
with the previously issued one for 
telecommunications pathways and 
spaces, provides organizations with 
advice on designing their buildings 
to meet telecommunications require¬ 
ments. By recommending distances 
from wiring closets to work areas as 
well as a number of cable choices, 
these standards provide stable tar¬ 
gets for manufacturers developing 
networks. Unfortunately, the wide 
variety of data rates and regulatory 
constraints on electromagnetic inter¬ 


ference (EMI) do not permit the stan¬ 
dards to present a single cable 
choice as a universal media. The de¬ 
velopment of the standards encour¬ 
ages manufacturers to make their 
network implementations available 
on a broad range of the recom¬ 
mended media. 

In the contemporary workplace, 
LANs are being installed as widely 
as telephones. Manufacturers have 
made ease-of-configuration (how the 
network is physically intercon¬ 
nected) a major objective so installa¬ 
tion and reconfiguration cause little 
disruption. 



In the contemporary 
workplace, LANs are 
being installed as widely 
as telephones. 


Reliability and 
Manageability 

In a remarkably short period of time, 
LANs have become indispensable to 
users. Their importance in the work¬ 
place demands a level of reliability 
second-to-none. Many people spend 
more time using LANs than tele¬ 
phones. The network needs to oper¬ 
ate virtually 24 hours a day, seven 
days a week, without interruption. 
Further, because LANs have become 
a utility like the telephone, they 
should not require a network opera¬ 
tor to tend to their needs. Instead, 
LANs are managed. The IEEE 
Token Ring Standard provides rules 
for this management that allow vari¬ 
ous manufacturers to implement 


schemes to meet their customers’ 
needs. IBM’s LAN Manager, for ex¬ 
ample, allows a single personal com¬ 
puter to monitor the activities of 
large, multiple-segment LANs. LAN 
Manager also communicates with 
Net View at the host computer to pro¬ 
vide a single point of management 
for the entire establishment network. 
With good network management, 
LANs operate invisibly to serve you 
continually. 

It All Has to Work Together 

IBM's commitment to networking 
extends from the LANs in your of¬ 
fice to the wide area networks that 
connect people around the world. 
IBM is an active supporter of all in¬ 
dustry standards that will help peo¬ 
ple share information, whether the 
information is in the next office or 
on the next continent. LANs are the 
basic building blocks to this commit¬ 
ment, because they operate in your 
local environment. If your LAN has 
the characteristics outlined in this ar¬ 
ticle, it will improve your ability to 
share information. 
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And You 
Thought LANs 
Were Just for 
the Office! 

Larry Lee 
IBM Corporation 
Owe go, New York 

Have you ever thought of a LAN 
operating in a “harsh environ¬ 
ment?” Here’s how standard com¬ 
mercial-grade PS/2s operated on a 
token ring LAN while strapped to 
a missile launcher on the side of 
an Apache helicopter. The PS/2s 
received considerable abuse - 
from vehicles running over ca¬ 
bling, to dust, rain, vibration and 
bugs - yet continued to work with¬ 
out a glitch. 

One mission of the IBM Federal Sec¬ 
tor Division in Owego, New York, 
is to build “black boxes” for the 
United States military. We build a 
variety of mission computers, receiv¬ 
ers, and communications equipment, 
which are used on all kinds of mili¬ 
tary platforms. As part of this devel¬ 
opment, PS/2s are used extensively 
for design, documentation, and 
testing. 

Recently, we had an interesting expe¬ 
rience with a semi-automated test 
system that we developed. We took 
it to McDonnell Douglas Helicopter 
Company’s facility in Mesa, Ari¬ 
zona, and tested one of these black 
boxes on an Apache helicopter. This 
involved using PS/2s to exercise the 
black box system, collect data, and 
analyze it in near-realtime. It’s not 
unusual to take a PS/2 into the field 
to test a system. But this case was 
unique. We took seven LAN- 
connected PS/2s and operated them 
as an integrated system. 


The black box system we tested is 
called the Radar Frequency Interfer¬ 
ometer System (RFIS). To the lay¬ 
man, it can be thought of as a big 
radar detector. We tested RFIS ex¬ 
tensively in our anechoic chambers 
in Owego and were under contract 
to determine its installed perfor¬ 
mance on an Apache helicopter. 

We planned to install RFIS on the 
helicopter, radiate it with known 
radar frequency signals, and monitor 
the emitter reports that RFIS was 
generating. We needed to sweep the 
frequency from a low to a high one 
in as many discrete steps as possi¬ 
ble. At each frequency we collected 
several samples of two types of data. 
The information collected at each 
frequency was a combination of 
emitter reports on a MIL STD 
1553B data bus and other data inter¬ 
nal to RFIS. The internal informa¬ 
tion was accessed through a special 
test port on the RFIS processor. 

After completing one full-frequency 
sweep, we called on a radio to ask 
that the helicopter be repositioned to 
a new azimuth angle. We could then 
perform another frequency sweep. 
Because of the manual positioning, 
it was considered a semi-automated 
system. We had to wait while the he¬ 
licopter was manually repositioned 
on the tarmac in front of our anten¬ 
nas. After we collected data over the 
azimuth angles of interest, we ana¬ 
lyzed the data and produced graphs 
of the systems’ performance. RFIS 
was tested with the rotor blades turn¬ 
ing so we could see exactly what af¬ 
fect the rotating rotor blades had on 
RFIS system performance. 

We performed quite a bit of this test¬ 
ing in our anechoic chambers, but 
with RFIS mounted on a precision 
turntable instead of on a helicopter. 
The chamber data became our perfor¬ 
mance baseline and was the best our 


system could perform because it was 
operating in a nearly ideal environ¬ 
ment. Field test data would point out 
any degradation in performance due 
to installation effects of the Apache 
helicopter. 

The test systems used in our cham¬ 
bers were unavailable to us for field 
work. The systems were part of the 
anechoic chamber and would be 
needed for other projects while we 
were in the field. 

We needed to design an automated 
data collection system to collect as 
much data as possible in a limited 
amount of time. 

History 

In previous field tests similar to this 
one, we used a few independently 
operated PS/2s. This approach 
worked, but definitely had its limita¬ 
tions. Typically, the RF generators 
were PS/2-controlled and were 
located several hundred feet away 
from the helicopter. There was also 
a PS/2 located within a few feet of 
the helicopter to monitor system per¬ 
formance and gather data. The opera¬ 
tors at the two sites communicated 
by radio. 

There were constant communication 
problems between the two sites. 

This was a primary concern, because 
we needed radio communication be¬ 
tween the sites and the helicopter. 
Radio problems included rundown 
batteries and garbled messages 
caused by noisy helicopter rotors 
and engines. Only one person could 
talk at a time. Also, radios are not se¬ 
cure, so we were not always able to 
freely discuss classified information 
with each other. 

Another concern was personnel staff¬ 
ing. People were frequently out of 
position during tests, and we did not 
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want to waste valuable time moving 
people among test sites. 

The unfortunate person who gets the 
assignment of working under rotat¬ 
ing helicopter blades has an espe¬ 
cially tough task. An incredible 
amount of noise is produced by the 
jet engines and rotor blades on the 
helicopter, and there is constant buf¬ 
feting by the rotor wash. Ear protec¬ 
tion is a must. It is very difficult 
trying to communicate and work up 
to eight hours a day in this noisy 
environment. 

In past tests, we never were able to 
analyze our data in realtime. Part of 
the problem was that we did not 
have instant access to the data being 
collected. The data from the RFIS 
system went to a flight recorder on 
the helicopter and later was trans¬ 
ferred to PS/2-compatible format. 



The unfortunate person 
who gets the assignment 
of working under rotating 
helicopter blades has an 
especially tough task. 


The transfer process might take a 
day or two depending on many exter¬ 
nal factors out of our control. 

Analyses would be done overnight 
after we obtained the data, or over a 
weekend or after we arrived home. 

If there was a problem with the data, 
we might not know about it until 
two or three days later and maybe 


not until the tests were over. To en¬ 
sure that our data was accurate, we 
needed near realtime analysis capa¬ 
bility to ensure the quality of our 
data. For these reasons, it was deter¬ 
mined that a new data collection sys¬ 
tem was needed. 

The New System 

For the new data collection system, 
we wanted to have instant access to 
the data. We also wanted to keep 
our test group away from the heli¬ 
copter and close together in order to 
improve communications and mini¬ 
mize transition time. We planned to 
have a trailer about 300 feet away 
from the helicopter and most PS/2s 
and all RF signal generators would 
be located inside. All the PS/2s 
would be linked together on the 
LAN, and the ones outside the 
trailer would be controlled remotely 
from inside the trailer. This 
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approach would allow us to have ev¬ 
eryone working in a quiet, clean, 
safe room. In this room, we could 
discuss the tests while they were run¬ 
ning and see what was going on 
with any of the PS/2s. 

The staff decided on a PS/2-based 
system on a token ring LAN as the 
basic system architecture. Because 
the LAN would be small and tempo¬ 
rary, we decided to keep things 
simple. As a result, we selected 
DOS-based PS/2s running PC LAN 
Program Version 1.3, Base Services. 
The system block diagram is shown 
in Figure 1. 

Hardware Selection 

The PS/2s used were not the ones 
we requested, but we compromised 
because they were needed quickly. 
We did not have time to determine 
how much processor power would 
be needed to perform any of the 
tasks or whether the LAN would be 
fast enough to handle the data rates 
anticipated. The determination was 
calculated by the “seat-of-the-pants” 
method because of our short develop¬ 
ment schedule. Our “gut feelings” 
told us we had more “horsepower” 
than we needed, which turned out to 
be correct. 

Equipment 

Three PS/2 Model P70s were used. 
We were unfamiliar with the P70s, 
but after using them in the lab for a 
few days, they became prized posses¬ 
sions because they performed well. 

The PC AT was used, because it 
was an existing piece of lab equip¬ 
ment with a special-purpose card 
and software. We added a LAN card 
and upgraded DOS and added PC 
LAN Program software. 

The two PS/2 Model 80s (071 and 
321) and a PS/2 Model 70 used 


were normal desktop units. They 
were not industrial-grade or 
ruggedized. 

The LAN cards were the 16/4 mega¬ 
bit variety except for the one in the 
PC AT. This was one of the older 4 
MB cards, which resulted in the 
LAN running at the slower 4 MB 
rate. But the slower data rate never 
posed a problem. 

The Multistation Access Units 
(MAUs) used were standard, non- 
ruggedized, rack-mounted 8228 units. 



Throughout our time in 
Arizona, the STS and 
BUSMON PS/2s were 
attached with duct tape to 
a missile launcher, which 
was on the side of the 
helicopter. 


After we had our basic system archi¬ 
tecture in place, there were still a lot 
of questions about exactly where 
equipment would be located and 
how things would be interconnected. 
Some of the decisions about where 
and how PS/2s would be mounted 
were not made until we got to Mesa 
and showed the McDonnell Douglas 
staff our equipment and the lengths 
of some of our cables. 

The connections from the Software 
Test Station (STS) and Bus Monitor 
(BUSMON) PS/2s to the RFIS sys¬ 
tem proved to be quite difficult. Re¬ 
moving our test cables from the 
RFIS system involved lowering an 
instrumentation pallet from the bot¬ 


tom of the helicopter, which took 
about a half hour, 30 seconds to 
break the connections, and another 
half hour to put everything back to¬ 
gether. For this reason, we left the 
STS and BUSMON PS/2s perma¬ 
nently connected to the RFIS sys¬ 
tem. Throughout our time in 
Arizona, the STS and BUSMON 
PS/2s were attached with duct tape 
to a missile launcher, which was on 
the side of the helicopter. 

The mounting scheme is shown in 
the photo on the second page of this 
article. This approach was certainly 
less than ideal, but was the best we 
could do in the limited time avail¬ 
able. No vibration analysis on the 
way the PS/2s were mounted was 
ever performed. If the PS/2s broke, 
we knew we could call IBM Service 
and have them repaired or replaced 
overnight. If one broke, we couldn't 
let the helicopter sit idle while we 
waited to get our test equipment 
fixed. 

Remote Control 

Because the STS and BUSMON 
PS/2s were mounted on the missile 
launcher, neither of these PS/2s 
could have displays attached. There¬ 
fore, these PS/2s were operated ex¬ 
clusively by remote control. 
Fortunately, there is good variety of 
remote control programs available 
for use on LANs, and we selected 
one called “PCNETWRK.” The pro¬ 
gram was easy to install and use. 
With just a few small batch pro¬ 
grams, we set it up so any PS/2 in 
the network could control and reboot 
any other PS/2. With this program, 
we often had three PS/2s in the 
trailer simultaneously controlling 
three other PS/2s outside the trailer 
with no performance degradation to 
the LAN. 
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Figure 1 



. RFIS Longbow Characterization Field Test 
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The STS was placed under remote 
control first thing in the morning 
and stayed that way until we pow¬ 
ered off the helicopter in the eve¬ 
ning. The BUSMON PS/2 was 
under remote control only when we 
started it or if a problem was sus¬ 
pected somewhere. The RF CON¬ 
TROL PS/2 was originally in the 
trailer, and it was the PS/2 that con¬ 
trolled the sequence. Later in the se¬ 
ries, this PS/2 was placed on a cart 
and moved outside the trailer (see 
photo on this page) and was con¬ 
trolled remotely. Using remote con¬ 
trol versus a display proved 
advantageous, because we found it 
was nearly impossible to read the 
display in the bright Arizona sun. 

Hello Mesa! 

During the First days of testing, we 
were fine-tuning our system while 


collecting data. After collecting data 
for only a short time, we changed 
some of the BUSMON PS/2s operat¬ 
ing parameters to speed up our data 
taking. Using the remote control pro¬ 
gram, we had the BUSMON PS/2 re¬ 
compile its program with the new 
parameters in the middle of a test. 
This happened while the helicopter 
blades were turning. The only thing 
the people in the helicopter noticed 
was that one data point took slightly 
more time than the previous ones. 

After collecting data for several 
days, we observed that the 
BUSMON PS/2 hung up several 
times daily. Upon noticing this, we 
switched to remote control and all 
we saw was the DOS prompt. The 
program was “blown” for no appar¬ 
ent reason. However, we rebooted, 
and it functioned properly. After a 


few days, we looked at the 
BUSMON code. We found that 
pressing any key cleared the screen 
and returned to DOS. We guessed 
that a key on the Model 80 was 
being hit by something blown by the 
rotor wash. After an unsuccessful 
trial with a cardboard cover on the 
keyboard, we found the solution. 
Taping the spacebar so it couldn't ac¬ 
tivate prevented any further prob¬ 
lems. Excessive vibration activated 
the spacebar. 

At the end of the day, shutdown pro¬ 
cedure for the helicopter-mounted 
PS/2s consisted of turning the power 
off, unplugging the extension cord, 
detaching the LAN cable from the 
helicopter-mounted MAU, and clean¬ 
ing the dead bugs and dirt from the 
PS/2s. The LAN cable was rolled up 
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and stuffed under the trailer. We had 
no protective covers for the PS/2s. 

During the first days of testing, the 
helicopter was pulled into a hangar 
at night for maintenance. Later on, it 
was left outside all night with the 
PS/2s still attached. Fortunately, 
there was no dew in the morning. 

By testing in the autumn, we didn’t 
have to worry about excessively 
high temperatures. We never had a 
temperature-related failure of any 
kind. 

Cables 

We used standard IBM LAN cables 
intended for use indoors. The cables 
in the trailer were on the floor and 
taped down for safety. The 300-foot 
cable from the trailer to the helicop¬ 
ter consisted of two 150-foot cables 
with the connectors taped together. 
This cable was rolled up every night 
and stored under the trailer. In the 
morning, the cable was rolled out 


and connected to the MAU on the 
helicopter and secured with tape. 

The cable near the helicopter was se¬ 
cured with six to ten “shot bags.” 
These were cloth bags about the size 
of a five-pound bag of flour filled 
with lead shot. Each weighed about 
30 pounds. The weight prevented 
the cables from being picked up by 
the rotor wash and sucked into the 
rotors or engines. 



The cable was run over 
several times - the first 
time by a fire truck, 
which put noticeable flat 
spots on the cable but 
didn ’t affect data 
transmission. 


The only special precautions for dust 
or water were taping shut the floppy 
disk drives on the two helicopter- 
mounted PS/2s. We didn't tape the 
air vents on either of those PS/2s. It 
rained briefly one night, but fortu¬ 
nately the helicopter was in the han¬ 
gar. The cables were laid on a wet 
tarmac, and when the helicopter was 
rolled out, everything worked. 

The cable was run over several 
times - the first time by a fire truck, 
which put noticeable flat spots on 
the cable but didn’t affect data trans¬ 
mission. A few cars, small tractors, 
and the helicopter’s tail wheel also 
ran over the cable without any no¬ 
ticeable damage. However, when a 
small tractor pulled a big steel fix¬ 
ture over the cable, its steel wheels 
put very noticeable flat spots on the 
cable. Again, data integrity on the 
LAN was unaffected. 
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Picking Up Good 
Vibrations... 

After 10 days, we changed the setup 
to perform a different series of tests. 
We took the RF-controlled PS/2 and 
the RF generators out the trailer and 
moved them closer to the helicopter. 
Everything seemed to run fine for a 
while, then we noticed an occasional 
anomaly in the data - apparently 
there was a problem with the 
BUSMON PS/2. We tried to fix the 
problem remotely with a software 
patch, but it didn't work. Figuring 
we might have an intermittent con¬ 
nection in this PS/2, 1 monitored it 
while the rotors were turning. Stand¬ 
ing under the rotors, I was as¬ 
tounded by the incredible vibration 
and noise to which the PS/2s were 
subjected. The vibration was much 
worse outside on the missile 
launcher versus inside the helicopter. 

We shut down the rotors, took the 
cover off the Model 80, yet found 
no internal problems. All cards and 
cables were still in place. Later, we 
discovered a software timing prob¬ 
lem on the LAN caused by the way 
the BUSMON software was written. 
After reconfiguring, we discovered 
that there was too much delay in its 
one critical path. After a small con¬ 
figuration change, everything was 
working again. The Model 80 was 
subjected to tremendous vibration all 
day long, yet continued to work 
flawlessly. 

The two PS/2s on the helicopter 
were being subjected to incredible 
vibration, which was totally unex¬ 
pected. We knew there would be 
some vibration, but not nearly as 
much as we saw. Had we anticipated 
this, we never would have operated 
in this fashion. We continued using 


the mounting scheme hoping that be¬ 
cause both PS/2s had made it this 
long, they would last a few more 
days. Both PS/2s still worked per¬ 
fectly when we got back to Owego, 
despite 15 days of torture. 

One thing that probably helped our 
disk drives survive this vibration 
was a head-parking terminate-and- 
stay-resident (TSR) program. This 
program, which parks disk drive 
heads after 15 seconds of inactivity, 
was installed on all PS/2s. 



The testing was 
successful because of the 
flexibility and 
performance of the token 
ring LAN, augmented by 
the amazing reliability of 
the PS/2s. 


Other Things 

We had two modem-equipped PS/2s 
that allowed us to access the Owego 
VM systems. We used these links to 
transfer preliminary results to other 
engineers in Owego, and to obtain 
their suggestions, and to download 
software. 

As shown in Figure 1, the Grid 
laptop PS/2 remained in the trailer. 
The modem-equipped PS/2 Model 
P70 was taken to the hotel nightly to 
prepare the next day’s test card, up¬ 
load and download data, and to de¬ 
velop programs. 


Conclusion 

Despite a host of problems - exces¬ 
sive vibration, dust, temperature vari¬ 
ation, and unusual abuse of the LAN 
cable - we completed the entire 15- 
day test sequence with no PS/2 or 
LAN hardware failures of any kind. 
We collected over 60 million bytes 
of data from RFIS, far more than 
any previous test session. 

We couldn’t do as much near¬ 
realtime data analysis as planned, be¬ 
cause the scope of the task was 
much greater than originally esti¬ 
mated. However, we did sufficient 
analysis in Mesa to ensure the accu¬ 
racy of the data. We caught several 
problems early on, allowing us to re¬ 
cover and successfully complete the 
tests. Final analysis of the data re¬ 
quired two months’ work. 

With the LAN system used in this 
test, we were able to detect prob¬ 
lems with RFIS, with our own test 
equipment, and with equipment on 
the Apache. In fact, the testing was 
successful because of the flexibility 
and performance of the token ring 
LAN, augmented by the amazing re¬ 
liability of the PS/2s. 

ABOUT THE AUTHOR 

Larry Lee is a staff engineer at 
IBM's Federal Sector Division in 
Owego, New York. Presently , he is 
working as a systems engineer on 
the AN/ALR-76 ESM system used on 
the S3B aircraft. Since joining IBM 
in 1977, Larry has worked on a 
variety of electronic support 
measures systems for military 
customers. He received a bachelor 
of technology degree from the State 
University of New York at 
Binghamton. 


Personal Systems/Issue 3, 1991 



53 


Remote LAN 
Management 
Tools 


Daniel J. Mieczkowski and 
Marvin W. Boswell 
IBM Corporation 
Research Triangle Park , 

North Carolina 

The wall chart “IBM LAN-Based 
Communications Protocols” is 
inserted in this issue and 
accompanies this article. 

The IBM 16/4 Token-Ring Trace 
and Performance Program (TAP) 
and the IBM Distributed Console 
Access Facility (DCAF) constitute 
a powerful LAN management tool 
when used in conjunction with 
one another. This article details 
the features of each of these pro¬ 
grams and describes the advan¬ 
tages of using them together. 

In today’s environment, when a 
workstation on a local area network 
(LAN) encounters a problem, a tech¬ 
nician must physically go to the site 
to determine what caused the prob¬ 
lem. On-site, physical interaction is 
time-consuming and defeats the pur¬ 
pose of effective distributed 
processing. 

With the IBM Distributed Console 
Access Facility (part number 
73F6159), operators can take control 
of a DOS or OS/2 workstation and 
troubleshoot remotely. Operators 
from the controlling workstation can 
now manipulate or monitor OS/2 
full-screen applications or DOS text 
applications on the target worksta¬ 
tion (Figure 1). 

One tool available for tracing LAN 
traffic and monitoring LAN perfor¬ 
mance is IBM’s 16/4 Token-Ring 


Network Trace and Performance 
(TAP) program. When used in con¬ 
junction with DCAF, it provides re¬ 
mote problem-determination 
capabilities previously available 
only on site at the local ring. 

Distributed Console Access 
Facility 

Situation 1: Imagine this situation. 
Someone in the network is having a 
problem with a PS/2 application. Fi¬ 
nally, after becoming totally frus¬ 
trated, the user calls the help desk. 
After a lengthy discussion, the help¬ 
desk operator reaches an impasse. 


To troubleshoot effectively, the help¬ 
desk operator feels the only solution 
is to see what the user is doing. 

Situation 2: A large distributed net¬ 
work with multiple LAN servers is 
becoming an administrative night¬ 
mare. Each location requires trained 
personnel to handle day-to-day LAN 
administration tasks that could be 
handled more effectively from a cen¬ 
tral location. 

The Solution: There is a solution 
for both the user and the help-desk 
operator - IBM’s Distributed Con¬ 
sole Access Facility. With DCAF, 
the operator can take complete con- 
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trol of a remote workstation or moni¬ 
tor and see possible errors the user 
is making. The operator can take 
over the workstation as if sitting in 
front of it. 

From a central location, you can re¬ 
motely monitor or control DOS or 
OS/2 workstations. Communication 
can be through your existing SNA™ 
network, a local area network, or 
through an asynchronous connection. 

Once you have taken control of a 
workstation, you can perform func¬ 
tions such as configuring Communi¬ 
cations Manager profiles, viewing 
error logs, performing LAN server 
administration tasks, or running the 
trace and performance program. 

Terminology: A DCAF environ¬ 
ment is comprised of different com¬ 
ponents. The controlling workstation 
is the one that will initiate all DCAF 
sessions and takes over another 
workstation, known as the target 
workstation. The controlling station 
requires OS/2 EE 1.2 or higher, 
while the target station can be either 
OS/2 or PC-DOS 3.30 or higher. 

When a controlling workstation es¬ 
tablishes a session with the target 
workstation, the session will be in 
one of two modes - active or moni¬ 
tor. In active mode, the controlling 
workstation operator takes over both 
the keyboard and display of the tar¬ 
get workstation. In monitor mode, 
the target workstation operator re¬ 
tains control of the keyboard, but the 
display can be viewed at both con¬ 
trolling and target workstations. 

The DCAF gateway component is 
used to access LAN targets. The 
DCAF controlling station will estab¬ 
lish a session with the DCAF gate¬ 
way, which acts as a single entry 
point into a LAN. This configuration 
is required to establish a DCAF ses¬ 


sion to a DOS target, but is also ad¬ 
vantageous when accessing OS/2 tar¬ 
gets on a LAN. When the DCAF 
gateway is used, configuration re¬ 
quirements are reduced, and the 
need to run Communications Man¬ 
ager on the targets is eliminated. 

When using the DCAF gateway, you 
also need the DCAF LAN directory 
component. This component main¬ 
tains a list of available targets and 
their status. When a connection is 
made between the DCAF controlling 
station and the DCAF gateway, this 
list is displayed on the controlling 
station, allowing the operator to se¬ 
lect the target for the DCAF session. 

Communications: The following 
types of communications are found 
in a DCAF environment: 

Switched asynchronous - uses the 
ACDI function of Communications 
Manager. This method can be used 
for communications between the con¬ 
trolling station and an OS/2 target, 
or between a controlling station and 
the DCAF gateway 

SNA - uses the APPC function of 
Communications Manager over all 
OS/2-supported Data Link Control 
protocols (for example, 

IBMTRNET, SDLC, X.25, and so 
forth). This method can be used be¬ 
tween a controlling station and an 
OS/2 target, or between a control¬ 
ling station and the DCAF gateway 

NetBIOS - is the protocol used be¬ 
tween the DCAF gateway and tar¬ 
gets on the LAN (token ring, 
Ethernet, or PC Network). This is 
the only method of communicating 
with DOS targets. 

Environment: A limitation of 
DCAF is its inability to work with 
Presentation Manager screens. This, 
however, does not mean that only 


workstations with full-screen text 
sessions can use DCAF. One of its 
capabilities is to open a full-screen 
session on an OS/2 target. Although 
the limitation still exists, the control¬ 
ling DCAF operator can access all 
full-screen sessions of the 
workstation. 

One DCAF function available exclu¬ 
sively on OS/2 workstations is file 
transfer capability, which is a bidi¬ 
rectional, single file function. To 
keep DOS memory requirements as 
low as possible, this function was 
not included for DOS targets. To use 
DCAF for transferring DOS files, 
first copy the file to an OS/2 server 
that is also a DCAF target. Then es¬ 
tablish a session with the OS/2 tar¬ 
get and use the DCAF file transfer 
function. 

Trace and Performance 

The IBM 16/4 Token-Ring Network 
Trace and Performance (TAP) tool 
lets users trace and analyze 16 or 4 
Mbps token ring networks, as well 
as monitor performance of those 
rings. TAP is used for problem isola¬ 
tion and determination, optimizing 
ring performance, and as a token 
ring application development aid. 
This tool operates in three modes: 

• Trace 

• Performance monitoring 

• Traffic matrix 

The TAP program, part number 
93X5688, runs under DOS 3.30 or 
higher, and requires an IBM 16/4 
Trace and Performance adapter, part 
number 74F5121 (AT Bus), or part 
number 74F5130 (Micro Channel). 
When not used with the TAP pro¬ 
gram, they will operate as normal 
token ring adapters. 

When the adapter is used with TAP, 
the adapter transmits a sequence of 
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“trace present” frames to the LAN 
Manager functional address to an¬ 
nounce its presence on the token 
ring. If a LAN Manager anywhere 
on the network is configured to pre¬ 
vent tracing, the LAN Manager auto¬ 
matically issues a “remove ring 
station” frame. This causes the TAP 
adapter to remove itself from the 
ring, which inhibits any tracing. This 
security function is built into the 
TAP adapter and cannot be disabled. 

Trace: In trace mode, the TAP tool 
copies all frames on the ring seg¬ 
ment regardless of the destination ad¬ 
dress. Various trace options allow 
you to trace all or selected data, 
such as: 

• Data to trace 
— All frames 

— Media Access Control (MAC) 
frames only 

— Non-MAC frames only 

• First buffer or entire frame 

• Addresses 

— Destination 
— Source 

— Destination and source 

Up to 11 MB of data may be cap¬ 
tured using multiple data files. 

Use the trace analysis facility 
(RTAP) to review and analyze the 
data captured by the trace facility. 
RTAP enables you to display, print, 
or store the ring network address 
configuration, which is a summary 
of the frames captured by the trace 
facility, and the contents of each 
frame. 

The trace analysis facility provides 
protocol interpretation capability to 
help you understand the frame data. 
Interpretation is provided for the fol¬ 
lowing protocols: 


• MAC IEEE 802.5 (token ring) 

• Logical Link Control (LLC) 802.2 

• SNA 

• NetBIOS 

• TCP/IP 

These protocols and the interrelation¬ 
ship between them are illustrated in 
the IBM LAN-Based Communica¬ 
tions Protocols chart included as an 
insert with this issue. Contact your 
IBM representative for information 
on classes or manuals that clarify 
the information in this chart. 

Performance: The performance fa¬ 
cility is used to obtain token ring net¬ 
work performance and utilization 
measurements. This facility counts 
the number of frames and bytes pass¬ 
ing through the ring on which the 
TAP adapter is installed and saves 
this information in a file. By analyz¬ 
ing the performance data, you can 
obtain throughput measurements and 
determine ring utilization. 


Figure 2. Token Ring Utilization in % Panel 


While the performance facility is op¬ 
erating, it displays either of two 
panels that show the realtime perfor¬ 
mance of the ring in different for¬ 
mats. The first panel (Figure 2) 
displays two numbers and two bar 
graphs reflecting ring utilization. 

The upper number and bar graph rep¬ 
resent bandwidth utilization of all 
frames on the ring. The lower num¬ 
ber and bar graph represent the utili¬ 
zation of user data contained in the 
frames on the ring. The difference 
between the two values can be inter¬ 
preted as the MAC and LLC proto¬ 
col overhead. This display is 
updated every two seconds. 

The second panel uses a bar graph 
to illustrate the ring utilization over 
last two hours. This graph is updated 
every four minutes. 

From the data collected by the per¬ 
formance facility, the analysis facil¬ 
ity creates a summary of the overall 
ring utilization. The summary 
includes: 
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• Time period 

• Total number of frames per sec¬ 
ond and bits per second 

• Average percentage of bandwidth 
utilization 

• Frame size distribution 
percentages 

The analysis facility also creates 
graphs illustrating average perfor¬ 
mance measurements and tables 
showing the amount of ring traffic 
over a period of time. 

Traffic Matrix: The traffic matrix 
facility collects information about 
non-MAC frames sent between sta¬ 
tion pairs on the ring. This informa¬ 
tion can be used to determine: 

• Which stations are most active 

• How many frames each station is 
sending and receiving 

• Type and size of these frames 

With this facility, you can also deter¬ 
mine whether particular station pairs 
are exchanging unusually large 
amounts of data. 

Uses for TAP: There are many 
ways TAP is useful. Token ring com¬ 
munication problems are determined 
by using the trace and analysis por¬ 
tions of the tool. Performance mode 
and traffic matrix mode are used to 
determine how to reconfigure the 
ring for improved performance, 
throughput, and response time. 

TAP Through DCAF 

Both DCAF and TAP can be used 
for LAN management. They work to¬ 
gether to provide enhanced LAN 
management capabilities. All TAP 
program functions operate the same 
under control of DCAF as they do 


when operated at the local TAP 
workstation. 

TAP traces frames or measures utili¬ 
zation only on the ring segment to 
which it is connected. To provide 
the best coverage for your network, 
TAP workstations should be placed 
on the most heavily used rings in the 
network. This should be done unless 
you plan to install a TAP worksta¬ 
tion on every ring segment. For ex¬ 
ample, you may want TAP 
workstations on all backbone or 
apex rings or on any ring with a 
3174 or 37X5 gateway. You may 
also want to consider a portable 
PS/2 that can be moved from ring to 
ring when necessary. Regardless of 
the number and placement of the 
TAP workstations, they should all 
be DCAF-accessible. This allows 
tracing and performance measure¬ 
ment of remote rings from a central 
location. 

TAP/DCAF Requirements: In ad¬ 
dition to the DCAF and TAP system 
requirements, there are two other re¬ 
quirements for using TAP through 
DCAF. First, there must be two 
token ring adapter cards in the TAP 
workstation - one 16/4 TAP adapter 
and one token ring adapter. Second, 
Version 2.01 of the IBM 16/4 Token- 
Ring Network Trace and Perfor¬ 
mance program is required. This 
version is available at no charge to 
owners of Version 2.0. Simply order 
PTF #UR33813 through normal 
IBM service channels. This PTF 
changes the way the adapters are ini¬ 
tialized by the TAP program, which 
allows it to be used with DCAF. 

Procedure: DCAF should be in¬ 
cluded as part of the startup proce¬ 
dure on the DOS workstation that 
will be running TAP. The batch file 
DCAFDOS.BAT is created during 
DCAF installation. By including this 
file in the AUTOEXEC.BAT, the 


workstation will be started as a 
DCAF target. 

There are two adapters in the TAP 
workstation - one will be used for 
DCAF, and the other for TAP. At in¬ 
stallation, DCAF will be configured 
to use either the primary or alternate 
adapter. Every TAP operation allows 
you to select the adapter to use with 
a default of primary. The DCAF ses¬ 
sion will terminate if TAP attempts 
to use the same adapter as DCAF. 
Ensure that TAP and DCAF use dif¬ 
ferent adapters. 

Using parameter files with TAP 
helps users select the proper adapter 
to be used with DCAF. Parameter 
files provide a convenient way to 
configure various setups required in 
the TAP program, as they need to be 
selected and entered only once. On 
subsequent uses of TAP, the file can 
be recalled by entering the name on 
the command line. 

Remote LAN Management 

Delays seem to be an inherent part 
of current problem determination 
procedures. A user calls the help 
desk to report a problem on a LAN- 
attached workstation. The help-desk 
operator cannot resolve the problem, 
so it is routed to the next level of 
support. A network technician re¬ 
sponds to the call and determines 
that a trace is needed. After locating 
the TAP workstation, a trace is com¬ 
pleted, yet the technician needs help 
in analyzing the information. The 
trace file is copied (or printed) and 
passed to someone else for analysis. 
Eventually, the problem is resolved, 
but considerable time has passed. 
And usually, this time is signifi¬ 
cantly increased when dealing with 
remote locations. 

We now have the remote LAN man¬ 
agement tools that will greatly re- 
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duce these delays. DCAF can be 
used by the help-desk operator, the 
network technician, as well as others 
involved in problem determination 
and resolution. If DCAF is installed 
on all workstations on the network, 
the help-desk operator can see the 
problem more clearly, which results 
in faster problem identification. 

The network technician can use 
DCAF to trace the problem without 
typical delays. Even when the techni¬ 
cian needs assistance in analyzing 


the trace, DCAF can help. Either the 
trace file can be copied to an OS/2 
server and transferred using DCAF, 
or someone else can establish a 
DCAF session with the TAP work¬ 
station and view the trace file online. 

There are other advantages for using 
DCAF and TAP for remote LAN 
management. Remote ring perfor¬ 
mance can be monitored, allowing 
problems to be anticipated and 
changes made before they actually 
occur. More problems can be man¬ 


aged and resolved from a central lo¬ 
cation by taking advantage of local 
expertise. This can also reduce train¬ 
ing requirements at the remote loca¬ 
tions. The benefits of using these 
products include reduced time and 
expense in managing the network 
and more efficient use of LAN 
expertise. 

Using the Tools 

Let’s look at some situations where 
these products prove useful. 
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Situation 1: Your organization uses 
3174s as gateways for 3270 emula¬ 
tion. This weekend you are adding 
several new 3174s to the network. 

All of the workstations using these 
new control units as gateways need 
to have the destination address 
changed in the Communications 
Manager profile. There are two 
ways to approach this task - you can 
search out every workstation, or you 
can use DCAF to make the changes 
from a central location. The first 
method is laborious and time- 
consuming; the second is efficient 
and fast. 

Instead of searching from floor to 
floor and office to office to locate 
the workstations that need changing, 
you can remain in one location and 
access the stations with DCAF. With 
DCAF, Communications Manager 
profiles can be displayed, created, 
changed, or deleted. All of these 
changes can be made in a fraction of 
the time it used to take. 

Situation 2: A help-desk operator 
receives a frantic call from a user - 
everything worked fine yesterday, 
but today the user can’t sign onto 
the host. The screen shows a 
COM695 error. The user insists that 
nothing has been changed, but for 
some reason, the system is not work¬ 
ing. The help-desk operator opens a 
problem report and assigns it to a 
network technician. 

The network technician receives the 
problem report from the help desk 
and begins problem determination. 
Because the problem seems to affect 
only one user, the technician sus¬ 
pects that perhaps something really 
has been changed. Experience has 
shown the technician that the fastest 
way to resolve this type of problem 
is with a trace. 


This network is designed with a 
TAP workstation with DCAF on all 
rings with 37X5 gateways. The tech¬ 
nician starts a trace on the appropri¬ 
ate ring, selectively tracing only the 
workstation and gateway addresses. 
The technician calls the user so the 
operation can be tried again. Of 
course, the connection still fails, and 
the COM695 error is still appearing, 
but now a trace is running, and the 
technician will soon see exactly 
what is happening. 



DCAF adds a new 
dimension - electronic 
monitoring from 
anywhere on the network. 


The technician analyzes the trace by 
comparing the sequence of frames 
with an existing trace of a successful 
connection. A mismatch is found, in¬ 
dicating the workstation is sending 
some incorrect values from the Com¬ 
munications Manager profile. 

Without leaving the help desk, the 
technician establishes a DCAF ses¬ 
sion with the user’s workstation, 
changes the incorrect value in the 
Communications Manager profile, 
contacts the user, and asks the user 
to retry the operation. This time it 
works! The problem has been re¬ 
solved by taking advantage of the 
tools available for remote LAN 
management. 

Conclusion 

Before the release of the Distributed 
Console Access Facility and the cur¬ 
rent release of the 16/4 Trace and 


Performance Program, technicians 
had to physically monitor the site ex¬ 
periencing difficulty. DCAF, how¬ 
ever, adds a new dimension - 
electronic monitoring from any¬ 
where on the network. The combina¬ 
tion of DCAF and TAP makes best 
use of network experts by allowing 
them to remotely resolve users’ sys¬ 
tem problems. These tools are invalu¬ 
able to those responsible for 
managing and maintaining a local 
area network. 
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New Horizons 
for IBM’s 
Shielded 
Twisted-Pair 
Cabling 

Hank Foglia and Thomas Toher 
IBM Corporation 
Research Triangle Park 
North Carolina 

Today’s appetite for information 
and expanding applications has 
placed enormous requirements on 
the network transport system. 

This article explores solutions to 
these increasing demands that 
allow transmitting high-speed data 
and full-motion analog video on 
standard shielded twisted-pair 
cabling. 

In 1984, when the IBM Cabling Sys¬ 
tem first introduced its 150-ohm, 
shielded twisted-pair (STP) cable, 
the typical computer user communi¬ 
cated through a terminal to a com¬ 
puter in a “glass house.” Today, 
computing power that only a few 
years ago would have cost tens of 
thousands of dollars is sitting on 
desktops all over the world. This arti¬ 
cle focuses on the latest advances in 
transmitting 100 Mbps signals on 
STP as well as the simultaneous 
transmission of broadband video and 
baseband signals on STP. 

Today’s workstation still needs to 
communicate with a host computer 
to access common information and 
occasionally to take advantage of 
the mainframe’s massive processing 
power. In 1984, the first devices to 
use IBM’s new cable communicated 
with host systems at data rates that 
did not fully exploit the capabilities 
of the cable. 



Even the 1985 introduction of the 4 
Mbps IBM Token-Ring Network did 
not begin to stretch the cable’s inher¬ 
ent capabilities. The 16 Mbps imple¬ 
mentation of token ring seemed for 
a while to define the comfortable 
limits of the cable’s utility. Now, the 
experimental work of IBM engineers 
at Research Triangle Park has shown 
that there is life - and bandwidth - 
in the IBM Cabling System 150- 
ohm STP cables. 

IBM’s STP cables can support high 
data rate transmissions because of 
the shield that protects the environ¬ 
ment from electromagnetic interfer¬ 
ence (EMI). Equally important is 
that the signal on the cable is pro¬ 
tected from noise in the environment 
surrounding the cable. Furthermore, 
the shield structure helps to maintain 
the cable’s physical and transmis¬ 
sion integrity. 

The fundamental issues in telecom¬ 
munications transmission are easy to 
express. First, cable utility is limited 
by the laws of physics; and second, 
transmissions are regulated by the 
laws of man, notably regulatory re¬ 
quirements governing radiation of 
electronic signals into the environ¬ 
ment. These two sets of laws often 
interact in ways that are challenging 
to transmission systems engineers. 

In other words, not everything possi¬ 


ble in the realm of physical law is 
permissible by regulatory law. 

IBM engineers have had to look for 
ways to expand the utility of IBM 
Cabling System cables that stay 
within the bounds of both sets of 
law. Further, cables must still de¬ 
liver the level of reliability that IBM 
Cabling System users have come to 
expect. 

High-Speed (100 Mbps) 
Transmission on STP 

The American National Standard In¬ 
stitute (ANSI) Fiber Distributed 
Data Interface (FDDI) Standard 
Committee is currently investigating 
transmitting at 100 Mbps on copper 
lobes. IBM and other vendors have 
made a series of proposals to the 
standards committee. The IBM pro¬ 
posal addresses only 150-ohm 
shielded twisted-pair cabling (equiva¬ 
lent to IBM’s type 1 cable) as de¬ 
scribed in the Electronic Industries 
Association (EIA) Commercial 
Building Wiring Standard. 

IBM’s experience with typical un¬ 
shielded twisted-pair indicates that it 
is not a viable alternative for high 
data rate (100 Mbps) applications. 
This is because the high levels of 
electromagnetic interference (EMI) 
generated by such signals are diffi¬ 
cult to reduce to acceptable limits in 
a design that is both technically 
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Figure 1. Transceiver Bloek Diagram 
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Figure 2. Radiated EMI and FCC Limits 
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robust and cost-effective. IBM’s pro¬ 
posal was developed to meet the fol¬ 
lowing design criteria: 

• Media from the work area to the 
wiring closet will be 150-ohm 
shielded twisted-pair installed ac¬ 
cording to the recommendations 
in the Commercial Building Wir¬ 
ing Standard 

• Maximum lobe lengths of at least 
100 meters must be supported in 
accordance with the recommenda¬ 
tions of the IBM Cabling System 
for work area-to-wiring-closet 
cabling 

• Design must meet all radiation 
standard requirements 

• Standard FDDI four-out-of-five 
signal coding must be retained 

• Design must be robust and eco¬ 
nomical to build 

• Footprint of the copper trans¬ 
ceiver should be compatible with 
the optical fiber transceiver de¬ 
scribed in the FDDI standard 

IBM engineers have developed a pro¬ 
posal that meets these design cri¬ 
teria. Particular attention was paid to 
EMI mechanisms based upon drive 
currents and common mode noise. 
The proposed solution combines a re¬ 
duction in transmitter signal ampli¬ 
tude and the use of a wideband 
common mode output filter. An 
equalized receiver signal amplifier 
makes use of an optimized thresh¬ 
old. In addition, special consider¬ 
ation has been given to surge 
protection and signal grounding to 
make an environmentally robust de¬ 
sign. All of these considerations 
yield a design that meets the jitter 
limits in the FDDI standard as well 
as the governmental EMI limits 
(Figure 1). 

EMI must be considered for the 
whole system. However, because the 
proposal is for a shielded cable solu¬ 


tion, the electromagnetic radiation is 
reduced by the cable’s shield, which 
shunts the radiated signals to 
ground. The circuit proposed to the 
standard committee contains EMI 
common-mode filters in both the 
transmit and receive paths to limit 
further the common mode signal. 

The differential mode radiation is 
comparatively insignificant. In the 
relevant frequency range, that is 
from 30 to 200 MHz, the attenuation 
afforded by the filter approaches 
20 dB. 

Another component of EMI reduc¬ 
tion in this design is the limit placed 
on the output pulse envelope. IBM 
is proposing that the output pulse as 
measured at the transceiver’s D-shell 
connector should measure 200 milli¬ 
volts peak-to-peak with a rise time 
of one to three nanoseconds. The re¬ 
ceiver threshold level is set at 20 
millivolts peak-to-peak. The input 


pulse envelope at the receiver is ex¬ 
pected to be 40 millivolts peak-to- 
peak, minimum. 

The combination of the design con¬ 
siderations just described have been 
tested in the IBM Radiation Labora¬ 
tory at Research Triangle Park using 
engineering prototypes. The graph in 
Figure 2 shows the EMI limits for 
FCC Class A, CISPR 22A, and GOP 
(German) certification. Our tests of 
engineering prototypes in a variety 
of configurations have met the re¬ 
quirements of all three of these na¬ 
tional standards. 

Just as EMI considerations affect the 
design of the circuit, the amount of 
jitter in the signal is an important 
component of signal quality. The 
FDDI Standard has a Received Opti¬ 
cal Jitter Specification that we used 
as a benchmark. The graph in Figure 
3 also has a line for the phase- 
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locked loop capability described in 
Annex E of the ISO/IEC 9314-3 
standard for comparison. As shown 
from preliminary test results, engi¬ 
neering prototypes over various 
cable lengths indicate that the IBM 
design effectively limits the jitter 
component of the signal. IBM engi¬ 
neers and other standards committee 
members’ efforts will soon enable 
local area networks to operate 100 
Mbps FDDI LANs on standard STP 
lobe cabling. 

Broadband Video 
Capabilities of Shielded 
Twisted Pair 

Communication requirements in 
most organizations grow faster than 
cable plants can be modified to sup¬ 
port the new applications. Many or¬ 
ganizations already must support 
multiple LANs, interconnecting 
LANs, and broadband video for edu¬ 
cation, training, security, imaging, 
and videoconferencing. Installing 
and maintaining a separate coaxial 
cable plant to serve these broadband 
video needs is expensive, disruptive, 
and may not be necessary. 

Tests on shielded twisted-pair cable 
containing both aluminum foil and 
mesh shield have shown such cables 
to be generally uniform in their trans¬ 
mission parameters. The excellent 
shielding properties of these cables 
may allow simultaneous transmis¬ 
sion of broadband and baseband sig¬ 
nals within the same cable sheath. A 
video coupler, which is an experi¬ 
mental filtering device, has been de¬ 
signed to separate the two 
transmissions. Figure 4 illustrates 
the separation of these signals on the 
same cable. The figure shows fre¬ 
quency allocation occupied by the 
baseband data signals for the 4, 16, 
and 100 Mbps range. In addition, 
the broadband signals generally used 


for video transmission ranges from 
50 to 550 MHz, and higher. 

For each cable run where simulta¬ 
neous transmission is required, a 
video coupler is installed at each 
end of the cable, as shown in Figure 
5. Each coupler would have both a 
coaxial connector (for broadband) 
and a data connector (for baseband). 
The circuit in the coupler isolates 
the broadband and baseband signals 
from each other and directs each of 
the signals to its respective port 
while maintaining complete isolation 
from each other. 

By using the technique of frequency 
division multiplexing (FDM), 
greater cable bandwidth utilization 
can be achieved. Thus, the data and 
video signals each occupy only their 
respective bandwidths. In this way, 
the broadband video signal coexists 
with the data signal from the point 
where it is injected onto the cable in 
the wiring closet to where it is ex¬ 
tracted at the office. This additional 
flexibility of STP cable should be 
considered when selecting cables to 
support expanding information 
requirements. 

What’s Next? 

These new developments in our re¬ 
search are encouraging because they 
indicate new possibilities for extend¬ 
ing the useful life of the IBM Ca¬ 
bling System. Just as data rates have 
increased faster than almost anyone 
would have predicted even 20 years 
ago, innovations in copper cable ap¬ 
plications have accelerated to keep 
pace with the new demand. How¬ 
ever, no solution is ever permanent. 
Demand for multimedia instructional 
presentations delivered to the 
individual’s workplace are increas¬ 
ing; the techniques for creating these 
presentations are increasing in so¬ 
phistication and availability. 


As imaging applications begin to 
play a rapidly increasing role in our 
computing environments, we may ul¬ 
timately reach the absolute bounds 
of either the physical or regulatory 
laws that govern data transmission. 
Optical fiber is waiting in the wings 
to assume its place on stage. But for 
a while, the stage may be shared 
with IBM Cabling System copper ca¬ 
bles carrying broadband video and a 
4, 16, or even 100 Mbps LAN 
simultaneously. 
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Tuning and 
Self-Tuning 
Features of 
OS/2 LAN Server 

Tom Gordy 
IBM Corporation 
Dallas , Texas 

While several server products on 
the market are advertised as self¬ 
tuning, most users don’t realize 
that the OS/2 LAN Server has 
many self-tuning features. This ar¬ 
ticle discusses the automatic tun¬ 
ing features and how users can 
control them through the 
IBMLAN.INI parameter file. 

Features considered to be “self¬ 
tuning” may simply imply that the 
server product performs some auto¬ 
matic setup at initialization, and that 
the user has no control over what 
the server does. The LAN Server 
self-tuning features allow users to 
control how they are used. Such con¬ 
trol allows tailoring of the server for 
your applications, if desired. 

How Self-Tuning Helps Users 

The OS/2 LAN Server’s self-tuning 
features help users in many ways. 

For example, a user may require 
memory to be available to run local 
applications such as administrative 
functions, net run jobs, or command 
functions. If these types of memory¬ 
intensive jobs are not running, why 
shouldn’t the server grow or expand 
and use the available memory? If 
the server doesn’t need the memory, 
why should the memory be allocated 
to it? Allocating memory that will 
not be used is wasteful, and so is re¬ 
serving memory that will be used in¬ 
frequently. 


BIGBUFS and Memory 
Utilization 

The IBMLAN.INI BIGBUFS pro¬ 
vide a way to control memory utili¬ 
zation. These buffers are used in 
several ways, but most often for 
downloading code or performing 
COPY functions. For optimum per¬ 
formance, there should be at least a 
couple of BIGBUFS available when 
starting a function that can use “raw 
data transfers.” These transfers are 
used in COPY/XCOPY functions, 
code download, or as required by an 
application program. The question 
is, how many have to be set up for 
each user? One? Two? The answer 
almost always seems to be, “It de¬ 
pends.” So, what are you going to 
do? Guess? That’s what many peo¬ 
ple do, or they simply allocate a lot 
of buffers and hope. Well, the good 
news is, it’s hard to go wrong! 

SRVHEURISTICS Controls 

Now don’t flinch, but 
SRVHEURISTICS is where you go 
to control BIGBUFS. 
SRVHEURISTICS digits 17 and 18 
controls how memory is allocated to 
BIGBUFS and how long it stays allo¬ 
cated. The NUMBIGBUFS parame¬ 
ter defines how much memory you 
want the server to allocate for perma¬ 
nent BIGBUFS. Upon startup, you 
get three BIGBUFS assuming you 
asked for three or more. Additional 
permanent BIGBUFS are created as 
they are needed. The 
NUMBIGBUFS parameter sets a 
maximum number of BIGBUFS that 
will be created and used for reading 
from and writing to the server. If 
users require all these BIGBUFS to 
be created and still need more to use 
while writing to the server, the 
server will create more. 

Creation of “extra” BIGBUFS, 
known as dynamic BIGBUFS, is 
controlled by the SRVHEURISTICS 


digits 17 and 18. Not only are they 
are created as needed, but released 
when they are no longer needed. Be¬ 
cause allocating and creating the 
buffers takes cycles, you can use 
digit 17 to cause the server to wait 
for a varying period of time before 
releasing a dynamic BIGBUF. For 
best performance, this would be suf¬ 
ficient time to avoid the overhead 
whenever possible. 

The default, 1, releases the BIGBUF 
one second after it is no longer 
needed. You might choose to set this 
default to a higher value, like 3, 
which waits one minute. This value 
keeps the BIGBUF around longer, 
making it available if another user 
or function requires it before spend¬ 
ing the cycles to deallocate. 

When a buffer is needed and no 
memory is available, 
SRVHEURISTIC digit 18 deter¬ 
mines how often the server will try 
to allocate a buffer. The longer it 
waits, the less overhead you waste 
on a failure. New buffers are allo¬ 
cated from available server memory. 
If an application is using the mem¬ 
ory, the server will wait and retry 
until it gets the memory required for 
a new BIGBUF. Trying often can 
get you a buffer sooner, but if the 
memory is not available, trying too 
often can slow down the system. 

The default, 3, waits one minute be¬ 
tween tries. If, during one of these 
waits an already created BIGBUF be¬ 
comes available, it will be used and 
a new one will not be created. 

So the server “tunes itself’ for the 
number of BIGBUFS it has. But 
that’s not all! 

Tuning REQBUFS 

SRVHEURISTIC digit 13 can be 
used to allocate some of the avail¬ 
able BIGBUFS that will be used to 
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create more REQBUFS if the server 
runs out of REQBUFS, and some 
more buffer space is needed for pre¬ 
fetching data from the disk before a 
user requests it. These additional 
buffers are called “4 KB read-ahead 
buffers.” 

Have you ever seen the 
NET ERROR message that indicates 
that the server ran out of the re¬ 
source defined by the 
NUMREQBUFS parameter? There’s 
also a message for NUMB1GBUFS. 
If you enter the NET STAT SRV 
command, the last two lines of the 
server statistics screen show exactly 
how many times this has happened. 
By setting digit 13 to 9 (and having 
at least that many BIGBUFS), you 
can give the server an additional 144 
buffers to be used for prefetching 
data. 

Because the server creates these 
REQBUFS as required, this is an¬ 
other example of (controlled) auto¬ 
matic tuning of the server. If you 
allocate nine BIGBUFS to this func¬ 
tion, you won’t need 144 more 
NetBIOS commands before they can 
be used. You couldn’t define that 
many extra commands anyway. 
These buffers are used to hold data 
that requesters haven’t yet asked for, 
but which the server expects them to 



ask for soon. The data is not actually 
sent to the requesters until they ask 
for it. Having the data waiting in a 
buffer when a requester asks for it 
means the requester will get the re¬ 
quired data much faster than if the 
server had to read it from the disk. 
SRVHEURISTIC digit 13 defaults 
to 1. That’s enough memory to cre¬ 
ate 16 additional REQBUFS to hold 
data as required. If you have more 
than 20 users, you might increase 
this value. In fact, you might want 
to increase it by one for every 40 
users after that. 

Tuning Cache 

Another feature designed to help 
server performance is the way the 
server uses its cache. The cache is 
designed to allow many users to 
share frequently accessed data. In 
other words, the data is used in appli¬ 
cations that share files and do byte 
range “record” locking. That, in 
turn, indicates that the data is ran¬ 
domly accessed (probably by a data 
base). 

For these reasons, the OS/2 caches 
(DISKCACHE for FAT drives, or 
HPFS cache.exe for its drives) are 
designed to not cache sequential file 
accesses in OS/2 Version 1.3. If se¬ 
quential file I/O was cached, your 
cache could quickly fill with useless 


data - print files going to or from 
the spool queues, for instance, or 
programs that have been 
downloaded. 

It would be nice to support more 
cache, but the HPFS cache is limited 
to 2 MB, and the DISKCACHE can 
be no larger than 7.2 MB. There are 
many things to consider before 
changing the way cache is used. For 
example, if it takes one second to 
cache 200 KB of data, how many 
times would the data have to be re¬ 
used before the cache actually saved 
time overall? Is it likely the data 
will be used that many times before 
it is overlaid by newly cached data? 
Will the new data be used enough 
before it, in turn, is overlaid by 
some even newer data? These are 
not easy questions to answer. 

It may be nice to keep some of this 
sequential stuff in memory. For ex¬ 
ample, RIPL time can be halved if 
the RIPL image is memory-resident 
in the server. Program loads would 
be faster if programs were in mem¬ 
ory when needed. To accomplish 
this, create the VDISK when the sys¬ 
tem is started, copy the code to it in 
STARTUP.CMD, and share the 
VDISK at server startup. Then users 
can get programs from memory. 
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If you’re using the FAT file system 
and DISKCACHE, you have the op¬ 
tion of defining the maximum disk 
read length that will be cached. By 
default, this is 3.5 KB. Using the pa¬ 
rameters on the CONFIG.SYS 
DISKCACHE statement, you can in¬ 
crease this so disk reads up to 32 
sectors will be cached 
(DISKCACHE = xxxx,32). This 
could be handy for sequentially ac¬ 
cessed files if they could be cached 
when the first record is read. HPFS 
cache does not have this capability, 
and it will cache no reads over 2 KB 
(eight sectors). Therefore, HPFS is 
the best place to put your randomly 
accessed data files. If both file sys¬ 
tems and caches are used, you could 
have up to nearly 10 MB of cache. 
Be sure to check that your cache (or 
VDISK) does not force the server 
into a swapping mode. If that hap¬ 
pens, all tuning efforts will be 
wasted. 

Some users have found “another 
cache” in the INI file - 
MAXWRKCACHE, which is 
Microsoft’s term for the requester’s 
BIGBUFS. While it might seem 
strange to specify a number of buff¬ 
ers on the server and a total amount 
of memory (in 64 KB increments) at 
the requester, that’s the way it’s 
done. At any rate, 

MAXWRKCACHE isn’t a cache ex¬ 
cept in a very limited sense. If 
you’re using sequential I/O and start 
using BIGBUFS of data (the raw 
data transfers mentioned earlier), 
then the WRKCACHE is a cache for 
a single file. Actually, it’s more like 
reading a big block of data from a 
tape drive or something similar. 

Effect on Slow Bridges 

Okay, enough on caches. Let’s look 
at another tuning option to consider. 
LAN servers sending large (64 KB) 
messages on slow bridges (either 


bridges on slow telecommunications 
links or local bridges that are suffer¬ 
ing congestion) have caused prob¬ 
lems when the NetBIOS at the 
server timed out and disconnected 
the remote user. This occurs if the 
bridge could not forward data as fast 
as the server could send it. When 
this occurs, users see a SYS0240 
error message. Various tuning 
changes have been used to help this 
situation (for example, changing the 
802.2 T1 timer and setting 
NUMBIGBUFS to zero), but noth¬ 
ing cured it completely. And, there 
is no NetBIOS timer parameter to 
tune. 

There is a way to change the 
NetBIOS timer. SRVHEURISTICS 
digit 15, which determines the 
OPLOCK timeout, is also used for 
the NetBIOS timeout. Unfortunately, 
it’s not all that simple, because 
OPLOCK timeout is a 16-bit num¬ 
ber and NetBIOS timeout is an 8-bit 
number. Therefore, the NetBIOS 
timeout can be no higher than 255 
(and that is in .5-second intervals, so 
255 is really 127.5 seconds). Stuff¬ 
ing a 16-bit number into an 8-bit 
field changes its value in some cases 
because the result is modulo 255. To 
save you some arithmetic, here are 
the SRVHEURISTIC digit 15 val¬ 
ues, the OPLOCK timeouts, and the 
NetBIOS timeouts: 


Digit 15 

0 

1 

2 

3 

4 

5 

6 

7 

8 
9 


OPLOCK 

35 

70 

140 

210 

280 

350 

420 

490 

560 

640 


NetBIOS 

17.5 

35 

70 

105 

12 

47 

82 

117 

24 

64 


These times are all in seconds; conversion is 
not needed. 


To net this out, if you have the LAN 
Server 1.2 or 1.3 and slow (or con¬ 
gested) bridges, and if you are hav¬ 
ing problems with the server 
dropping NetBIOS sessions with re¬ 
questers on the “other” ring, set the 
SRVHEURISTICS digit 15 to 1, not 
the 0 default. If problems persist, 7 
is the greatest value you might try. 

If you do this, be aware that the 
OPLOCK time for a value of 7 is 
490 seconds. That is the time an ap¬ 
plication would have to wait before 
receiving an “access denied” mes¬ 
sage if the OPLOCK holder termi¬ 
nated abnormally. 

The good part is that if either server 
(1.2 or 1.3) drops the requester, the 
next time the requester tries to ac¬ 
cess the server, the dropped session 
is re-established automatically. 
Therefore, even if the user cannot 
perform the “slow” function, other 
jobs can continue on the requester or 
the function can be retried later. 

Summary 

The IBM LAN Server has several 
self-tuning features. Understanding 
how to control them through the 
IBMLAN.INI parameters can help 
you make the best use of the 
server’s resources in your 
installation. 
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NetWare 

Communications 
and Routing 
Protocols 

Paul Turner 
Novell Inc. 

Provo, Utah 

In the early days of local area net¬ 
works (LANs), the networks were 
simpler and usually had only one 
file server. People didn’t know 
about the communication pro¬ 
cesses between workstations and 
file servers. The LANs of today 
are much more complex with multi¬ 
ple servers and different types of 
protocols being used. Understand¬ 
ing how data moves through the 
network has now become essen¬ 
tial. This article explains how Net¬ 
Ware gets information from one 
place to another on a network. 


Routers perform a vital role in net¬ 
working. Their function is far more 
complex than simply passing pack¬ 
ets from one network segment to an¬ 
other. Routers share information 
with other routers on the network 
and are the focal point for dissemi¬ 
nating information on their particu¬ 
lar segment. To understand the 
various roles routers play requires an 
understanding of the mechanics of 
NetWare communications. 

When networks were simple systems 
with one file server on a single trunk 
cable, designers and installers didn’t 
need to know much about the com¬ 
munication processes that interacted 
between workstations and file serv¬ 
ers. They spent more time trying to 
get single-user software packages to 
run in a multi-user environment than 
worrying about internetworking 
issues. 


Since then, networks have become 
larger and more complex. Products 
such as multiprotocol routers and 
MAC-layer bridges, and protocol im¬ 
plementations such as token ring 
source routing and TCP/IP, are be¬ 
coming necessary elements in the de¬ 
sign of large internetworks. To 
successfully integrate these and 
other elements with NetWare, a 
solid understanding of the mechan¬ 
ics of NetWare’s communications 
environment is essential. 

Note that what Novell has tradition¬ 
ally called internal bridges (those 
within file servers) and external brid¬ 
ges are referred to as internal and ex¬ 
ternal routers to be consistent with 
standard industry terminology. 

Protocols for Exchanging 
Information 

Any in-depth discussion of the me¬ 
chanics of NetWare communications 
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Figure 1. Relationship of NetWare Protocols to OSI Model 


requires a good understanding of the 
various protocols NetWare uses. 
These protocols define both the lan¬ 
guage and the packet format used to 
exchange information over the 
network. 

Basically, seven different protocols 
are used for communication and 
packet routing within the native 
NetWare environment. These 
include: 

• Medium access protocols 

• Internet packet exchange (IPX) 

• Routing information protocol 

(RIP) 

• Service advertising protocol (SAP) 

• NetWare core protocol (NCP) 

• Sequenced packet exchange (SPX) 

• NetBIOS 

Figure 1 shows how these protocols 
relate to the layers in the open sys¬ 
tems interconnection (OSI) reference 
model. Although there is not a direct 
correlation in layer boundaries be¬ 
tween the two architectures, this rela¬ 
tive mapping gives you a general 
idea of where each protocol fits. 

As in the OSI model, the upper 
NetWare protocols (RIP and SAP) 


rely on the lower protocols (IPX and 
the medium access protocols) to take 
care of the lower-level communica¬ 
tion issues. This modular approach 
is the key to NetWare’s compatibil¬ 
ity with numerous network interface 
cards. 

Our discussion focuses on the first 
four protocols, because they deal 
most closely with NetWare commu¬ 
nication and routing. NCP, SPX, and 
NetBIOS are more concerned with 
peer-to-peer and client/server 
interaction. 

Medium Access Protocols 

Medium access protocols are de¬ 
fined by the network hardware being 
used. A number of these protocols 
have been developed, many of 
which can be used with NetWare. 
We’ll concentrate on the most com¬ 
mon medium access protocol imple¬ 
mentations: 802.5 token ring, 802.3 
Ethernet®, Ethernet version 2.0, and 
Arcnet. 

These implementations are primarily 
concerned with transporting packets 
from one node to another on a single 
network segment. They provide bit- 
level error checking in the form of a 
cyclic redundancy check (CRC). 


The CRC is appended to every 
packet transmitted, thus assuring that 
99.9999 percent of the packets that 
are successfully received are free of 
corruption. In view of this level of 
integrity, NetWare does not provide 
any additional bit-level error check¬ 
ing within any of its upper-level 
protocols. 

NetWare’s Addressing Scheme: 

The basis of any communication and 
routing methodology is the address¬ 
ing scheme employed to distinguish 
different entities on an internetwork. 
NetWare’s addressing is analogous 
to the postal service’s addressing sys¬ 
tem that identifies mail recipients by 
country, state, city, street, number, 
apartment, and individual names. 

The postal system can adopt the ad¬ 
dressing conventions of an apart¬ 
ment complex into its overall 
system. Similarly, one protocol can 
integrate another’s addressing 
scheme into its own - as in the case 
with IPX and the medium access 
protocols. 

The medium access protocol imple¬ 
mentations define the portion of the 
NetWare address that distinguishes 
each node on a network. Node ad¬ 
dressing is implemented within the 
hardware of each network interface 
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Routers 

452h - Service Advertising Protocol 
453h - Routing Information Protocol 

Workstations 

4003h-4007h - Communication with File Servers 
455h - NetBIOS 


Figure 2. Socket Number Uses 

card (NIC). To get a packet to the 
proper node on a network, a medium 
access control (MAC) header is 
placed at the front of every packet. 
The MAC header contains a source 
address Field and a destination ad¬ 
dress field that indicate where the 
packet originated and where it is 
going. If the destination address in 
the MAC header matches a NIC’s 
own node address, or if the packet is 


identified as a broadcast packet (in¬ 
tended for all nodes), the NIC makes 
a copy of the packet. 

The majority of medium access pro¬ 
tocol implementations provide bit- 
level error checking and node 
addressing. IBM’s token ring imple¬ 
mentation defines a method of rout¬ 
ing called source routing , which 
allows network traffic to be seg¬ 


mented by separating rings with 
IBM token ring bridges. This re¬ 
quires that each workstation main¬ 
tains a table containing routes to 
each node they are communicating 
with. To maintain these tables, rout¬ 
ing information must be included in 
the MAC header of each packet 
sent. Source routing can be used in¬ 
stead of, or in conjunction with, 
NetWare routing, as long as the net¬ 
work is laid out properly. 

Internet Packet Exchange 

Novell adopted its IPX protocol 
from the Xerox® Network System 
(XNS). IPX is a datagram-based, 
connectionless protocol. It is con¬ 
nectionless because it does not re¬ 
quire an acknowledgment for each 
packet sent. This packet acknowledg¬ 
ment, or connection control, must be 
provided by protocols above IPX. 

IPX defines internetwork and intra¬ 
node addressing schemes relying on 
the medium access protocol for node 
addressing. The network numbers as¬ 
signed in NETGEN for NetWare 
v2.1x form the basis of IPX’s inter¬ 
network addressing. Each network 
segment on a NetWare internetwork 
is assigned a unique network num¬ 
ber. NetWare routers use this num¬ 
ber to forward packets to the final 
destination segment, much like the 
postal service uses a street name. 
Once a packet reaches the final desti¬ 
nation segment, the node address is 
used to deliver the packet to the 
proper workstation or server. 

The IPX address for routing packets 
within a node comes in the form of 
socket numbers, which provide a 
quick method of routing packets 
within a node. Because several pro¬ 
cesses are normally operating within 
a node, sockets provide sort of a 
mail slot so each process can distin¬ 
guish itself to IPX. When a process 
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needs to communicate on the net¬ 
work, it requests that a socket be as¬ 
signed to it. Any packets that IPX 
receives that are addressed to that 
socket are passed on to the process. 
Novell has reserved several socket 
number for specific purposes 
(Figure 2). 

The network, node, and socket ad¬ 
dresses for both the destination and 
source are held within the packet’s 
IPX header. This header is placed 
after the MAC header and before the 
data packet. (A packet’s data can in¬ 
clude the headers of higher-level pro¬ 
tocols.) Figure 3 shows the structure 
of an IPX packet on an 802.3 
Ethernet network. 

Routing Information 
Protocol 

The RIP facilitates the exchange of 
routing information on a NetWare 
internetwork. Like IPX, the RIP was 
derived from XNS. However, a criti¬ 
cal change was made in the packet 
structure to improve the decision cri¬ 
teria for selecting the fastest route to 
a destination. This change prohibits 
the straight integration of NetWare’s 
RIP with other, undeviating XNS 
implementations. 

The single-packet structure defined 
by the RIP allows the following in¬ 
formation exchanges to take place: 

• Workstations can locate the fast¬ 
est route to a desired network 
number 

• Routers can request information 
from other routers in order to up¬ 
date their internal tables 

• Routers can respond to requests 
from routers and workstations 

• Routers perform periodic broad¬ 
casts to ensure that all other rout¬ 
ers are aware of the current 
internetwork configuration 


MAC Header 
IPX Header 


Routing 

Information 


XXXXXXXXXXXXXXXXXXX 


XXXXXXXXXXXXXXXXXXX 


Operation 
Network Number 


Number of Hops 
Number of Ticks 


Network Number 


Number of Hops 
Number of Ticks 


Figure 4. Routing Information Protocol Packet Structure 


Each of these information exchanges 
will be discussed in more detail with 
the mechanics of NetWare routing. 

RIP Packet Structure: Figure 4 
shows the structure of a RIP packet. 
The structure of the RIP packet is en¬ 
veloped within the data area of a 
standard IPX packet. 

The operation field indicates 
whether the RIP packet is a request 
or response. A response packet can 
be either a reply to a request from a 
router or workstation, or a periodic 
broadcast by a router. 

Following the operation field, the 
packet can hold one or more sets of 
routing information, each consisting 
of a network number and number of 
hops and ticks it takes to get to that 
network number. 

A hop is counted every time a 
packet passes through a router to 
reach a network number. Routers in¬ 


clude themselves as one hop when 
counting the total number of hops. 

A tick is roughly one-eighteenth of a 
second. (There are 18.21 ticks in a 
second, to be precise.) The total 
number of ticks measures how much 
time it takes to reach the network 
number. The original XNS definition 
of the RIP did not include the “num¬ 
ber of ticks” field; it relied solely on 
the number of hops to determine the 
fastest route to a destination. 

NetWare developers added the time 
field to integrate NetWare with a va¬ 
riety of transport mechanisms (such 
as asynchronous, X.25, and Tl). 

If the packet is a request for informa¬ 
tion, only the network number field 
applies - the hops and ticks fields 
are essentially nulled out. 

Service Advertising Protocol 

The SAP allows nodes that provide 
a service (like file servers, print serv¬ 
ers, and gateway servers) to adver- 
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MAC Header 
IPX Header 


SAP 

Information 


XXXXXXXXXXXXXXXXXXX 


XXXXXXXXXXXXXXXXXXX 


Operation 


Service Type 


Server Name 


Network Address 


Node Address 


Socket Number 


Number of Hops 


Figure 5. Service Advertising Protocol Packet Structure 


tise their services and addresses. The 
SAP is an adaptation that makes the 
process of adding and removing ser¬ 
vices on a network more dynamic. 

Through the SAP, clients on the net¬ 
work can determine what services 
are available and obtain the inter¬ 
network address of the nodes (serv¬ 
ers) where they can access those 
services. This is an important func¬ 
tion, because a workstation could 
not initiate a session with a file 
server without first obtaining the 
server’s address. 

For example, a gateway server 
broadcasts a SAP packet every 60 
seconds - a period defined for all 
servers advertising with the SAP - 
onto the network segment to which 
it is connected. Each router on that 
network segment copies the informa¬ 
tion in this SAP packet into an 
internal table called the server infor¬ 
mation table. Because each router 
keeps up-to-date information on 
available servers, a client wanting to 
locate the gateway server can access 
a nearby router for the address. 

Like the RIP, the SAP uses IPX and 
the medium access protocol for its 
transport. Figure 5 illustrates the 
SAP packet structure. 

Again, the first field after the IPX 
header defines the operation the 
packet is performing. There are four 
possible operations: 

1) A request by a workstation for 
the name and address of the nearest 
certain type of server. For example, 
the workstation might essentially 
say, “Give me the name and inter¬ 
network address of the nearest file 
server.” This request would be repre¬ 
sented by a “get nearest server” 
entry on the NetWare TRACK ON 
screen. (TRACK ON is a utility 
available at the file server or exter¬ 


nal router console that allows an ad¬ 
ministrator to track RIP and SAP ex¬ 
changes on the network. It is 
accessed by typing “track on” at the 
colon (:) prompt.) 

(2) A response to a Get Nearest 
Server request. (This response would 
be seen as a “give nearest server” 
entry on the TRACK ON screen.) 

(3) A general request for the names 
and addresses of all servers, or all 
servers of a certain type, on the inter¬ 
network (seen as “Send All Server 
Info” on the TRACK ON screen). 

(4) A response to a general request. 

Following the operation field are 
one or more sets of SAP information 
fields, each containing the following 
information about a server: 

• A number representing the type 
of service provided by the server 

• The server’s name and address 


• The number of hops to the server 

The Mechanics of Packet 
Routing 

The purpose of routing is to pass 
packets from one network segment 
to another using the fastest possible 
path to the final destination. Both 
the determination of the fastest path 
and the actual passing of packets are 
performed by routers that reside ei¬ 
ther within file servers or in external 
boxes. Routing is necessary only 
when the sending and receiving 
nodes reside on different network 
segments separated by one or more 
routers. 

Sending a Packet: The sending 
node must have the full address (net¬ 
work, node, and socket) of the desti¬ 
nation node before sending the 
packet. The sender places this ad¬ 
dress in the destination address 
fields of the IPX header. It also 
places its own address in the source 
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a. Transmission to same network segment (no routing required) 



b. Transmission to directly connected network segment 



Figures 6a and b. How MAC and IPX Headers Are Used in Routing 


address fields so the receiver knows 
to whom it should respond. 

If the destination network number is 
the same as its own, the sender 
places the same set of destination 
and source node addresses in the 


MAC header and transmits the 
packet (Figure 6a). 

If the packet is destined for a differ¬ 
ent network number, the sender has 
to send the packet to a router that 
can forward the packet. It is not nec¬ 
essary for the sender to know the en¬ 


tire route to the destination, as in 
source routing. It only has to locate 
the router on its local network seg¬ 
ment that registers the shortest path 
to the destination network number 
and send the packet there. 
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The sender finds the appropriate 
router by locally broadcasting a re¬ 
quest for the shortest route the desti¬ 
nation network number. (Local 
broadcasts are not forwarded to 
other network segments by routers.) 
The router with the shortest route re¬ 
sponds to the request giving its own 
node address, plus the total number 
of routers (hops), and total time in 
eighteenths of a second (ticks) neces¬ 
sary to reach the desired network 
number. 

To send the packet, the sender 
places the node address of the router 
in the MAC header’s destination ad¬ 
dress field and its own node address 
in the source address field, leaves 
the IPX header as previously set, 
and transmits the packet. When the 
router receives the packet, it checks 
the destination address fields of the 
IPX header to determine what action 
should be taken (Figure 6b). 

At the Router: NetWare routers 
maintain a routing information table 
that holds information about all of 
the network segments on the inter¬ 
network. Each entry in this table 
tells the router how to forward 
packets so they reach a particular 
network segment. With this informa¬ 
tion, the router acts like the flight at¬ 
tendant who directs you to your 
connecting flight as you deplane. 

The network segments are arranged 
by network number. The router sim¬ 
ply matches the destination network 
number in the packet’s IPX header 
with an entry in its routing informa¬ 
tion table to get its forwarding in¬ 
structions. There are three possible 
instructions for forwarding the 
packet: 

(1) If the router is an internal router 
and the packet is addressed to that 
file server, the packet is passed di¬ 


rectly to the file server for 
processing. 

(2) If the packet is destined for a net¬ 
work number to which the router is 
directly connected, the router places 
the destination node address from 
the IPX header in the destination ad¬ 
dress field of the MAC header, 
places its own node address in the 
source address field of the MAC 
header, and transmits the packet. 

(3) If the router must send the 
packet to another to reach the desti¬ 
nation network number, the router 
obtains the next one’s node address 
from its routing information table. It 
places that address in the destination 
address field of the MAC header, 
places its own in the source address 
field, and transmits the packet on the 
appropriate NIC. 

It’s important to realize that the IPX 
destination and source address fields 
have not been changed during any 
of these examples. They remain the 
same for two reasons: so subsequent 
routers (if any) can follow the same 
algorithms as the first router did, 
and so the final destination node 
knows to whom to respond. Also, 
the packet does not keep a record of 
the path taken to reach its destina¬ 
tion. The only modification that the 
router makes to the IPX header is in¬ 
crementing the transport control 
field, which counts how many rout¬ 
ers the packet has passed through. 

Spreading the Routing 
Information 

Now that we’ve covered the process 
of routing, let’s talk about the admin¬ 
istrative processes going on in the 
background. On an active internet¬ 
work, routers are constantly exchang¬ 
ing information with each other to 
make sure that their routing informa¬ 
tion tables reflect up-to-the-minute 


changes in the layout of the internet¬ 
work. To maintain current informa¬ 
tion in their tables, routers transmit a 
series of broadcasts (using the RIP) 
from the time they come up until 
they are eventually brought down. 
These broadcasts can be separated 
by the time at which they occur: 

(1) First, there’s an initial broadcast 
of directly connected network 
segments 

(2) Next, there’s an initial request to 
receive routing information from 
other routers 

(3) After these initial broadcasts, 
routers perform periodic broadcasts 
(every 60 seconds) of the current list 
of active network numbers 

(4) When necessary, routers send 
broadcasts notifying other routers of 
a change in the internetwork 
configuration 

(5) When a router is brought down, 
it issues a final broadcast 

Although broadcasts occur at differ¬ 
ent times, and for the most part con¬ 
tain different information, they must 
follow two important guidelines. 
First, each broadcast must be a local 
broadcast, addressed so it will not be 
immediately passed on intact by the 
routers that receive it. This reduces 
the network load created by these in¬ 
formation exchanges. Second, rout¬ 
ers must follow a best information 
algorithm when providing informa¬ 
tion to other routers through a broad¬ 
cast. (Requests for information, such 
as the second broadcast previously 
listed, are not subject to the best in¬ 
formation algorithm.) 

The Best Information Algorithm: 

The purpose of routing information 
broadcasts is twofold: to allow a 
router to share its current impression 
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Figure 7. Sample Four-Segment Internetwork 


of the layout of internetwork with 
other routers, and to inform other 
routers of a change that can update 
their tables. 

A router sends routing information 
broadcasts to every network segment 
to which it is directly connected. 

The first rule of the best information 
algorithm dictates that a router about 
to broadcast onto a particular net¬ 
work segment should not include 
any information about other seg¬ 
ments it has received from that seg¬ 
ment. For example, if the router 
within server FS2 in Figure 7 is 
going to send a routing information 
broadcast onto network segment BB, 
it should not include information it 
received from FS1 about network 
segment AA. If it did, someone on 
segment BB might erroneously con¬ 
clude that there are two paths to seg¬ 
ment AA (one through FS 1 and 
another through FS2). 

This algorithm also states that rout¬ 
ers should not include information 
about the network segment to which 
information is being sent. For exam¬ 
ple, FS2 would not include informa¬ 
tion about BB in its broadcast onto 
BB. Therefore, the information that 
FS2 broadcasts onto segment BB 
would be information about seg¬ 
ments CC and DD. 


Routing Information Broadcasts: 

When a router is first brought up, it 
places network numbers of its di¬ 
rectly connected segments into its 
routing information table. Then, fol¬ 
lowing the best information algo¬ 
rithm, the router sends a routing 
information broadcast to inform the 
routers on its directly connected seg¬ 
ments of the segments it will now 
make available. The router next 
broadcasts a request onto each of its 
directly connected segments for in¬ 
formation about all other network 
segments on the network. All routers 
on its directly connected segments 
respond to this request (each using 
the best information algorithm). The 
router places the information 
gleaned from these responses in its 
routing information table. Figures 
8a, b, and c illustrate this sequence 
of initial broadcasts. 

Once a router has performed these 
initial broadcasts and updated its 
routing information table, it is ready 
to route packets. In addition to rout¬ 
ing packets, every 60 seconds the 
router broadcasts all the information 
in its routing information table (ex¬ 
cept that excluded by the best infor¬ 
mation algorithm) onto each of its 
connected network segments. Rout¬ 
ers perform these periodic broad¬ 
casts to ensure that all routers on the 
internetwork remain synchronized. 


Figure 8d shows an example of such 
a broadcast. (Because of their low 
bandwidth limitations, X.25 and 
asynchronous links do not perform 
60-second broadcasts.) 

Changes on the Internet: When a 
router receives information that 
causes it to change its routing infor¬ 
mation table, it immediately passes 
that information to its other con¬ 
nected network segments. That is, 
all segments except the one on 
which received the new information. 
Therefore, if a new network segment 
comes up or an existing one goes 
down, all routers on the inter¬ 
network hear about it quickly. 

If a router needs to be brought down 
(via the DOWN command at the 
console), it informs its peers before 
discontinuing service. Using the best 
information algorithm, it issues 
broadcasts indicating that the net¬ 
work segments it made available 
will no longer be accessible through 
this router - though they may still 
be available through another router 
(Figure 9). 

On the other hand, if a hardware fail¬ 
ure, power glitch, or - though this 
never happens - a user turning it off, 
causes a router to go down without 
the DOWN command, other routers 
will not immediately be aware that a 
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a. Initial Broadcast 

Print Server 


AA 




b. Initial Request 

Print Server 


AA 




Gateway Server 



DD 



c. Response from 

Print Server 




BB 


FS2 



cc 


FS3 


Gateway Server 


DD 




AA (1 Hop, 2 Ticks) DD (1 Hop, 2 Ticks) 



CC (1 Hop, 2 Ticks) BB (1 Hop, 2 Ticks) 

DD (2 Hops, 3 Ticks) AA (2 Hops, 3 Ticks) 


Figures 8a, b, c, and d. Building and Maintaining a Routing Information Table 


Personal Systems/Issue 3, 1991 



















































































76 


change has occurred. To safeguard 
against this, an “aging” mechanism 
is built into NetWare routers. Rout¬ 
ers maintain a timer for each entry 
in their routing information table. 
Every time information is received 
concerning the entry, the timer is 
reset to zero. If the count on the 
timer reaches three minutes, the 
router assumes that the route to the 
network number referenced by that 
entry is down and broadcasts that to 
its other segments. Because this is 
new or changed information, routers 
that receive it will pass it on immedi¬ 
ately and news of the change 
quickly permeates throughout the 
internetwork. 

Advertising Services with 
SAP 

The method of broadcasting pre¬ 
viously described for distributing 
routing information across an inter¬ 
network is also used for circulating 
server information. As servers broad¬ 
cast their services and addresses 
with SAP, routers collect the infor¬ 
mation in their server information ta¬ 
bles. They will subsequently pass on 
this information to other routers 
through SAP broadcasts. 


An internal router residing in a 
server performs an initial server in¬ 
formation broadcast and a request 
for server information from other 
routers updates its server informa¬ 
tion table. Thereafter, the internal 
router performs broadcasts about the 
servers that it is aware of every 60 
seconds (except on asynchronous 
and X.25 links). 

As with routing information broad¬ 
casts, all server information broad¬ 
casts are local and are subject to the 
best information algorithm. Any 
changes in server information are 
passed on immediately to ensure cur¬ 
rent information across the inter¬ 
network. The router applies the 
aging process for its server informa¬ 
tion table entries in case any servers 
have become unavailable. Finally, as 
the server is brought down, it indi¬ 
cates to its peers that the servers it 
has been advertising are no longer 
available. 

Using the SAP, a workstation can 
broadcast a request onto the segment 
it resides on to get the name and ad¬ 
dress of the nearest server of a cer¬ 
tain type. All routers with access to 
the closest server on the segment re¬ 


spond to this request. If several inter¬ 
nal routers exist on the network, 
they will answer with the name of 
the server where they reside (regis¬ 
tered as one hop away). Any exter¬ 
nal routers on the segment will not 
answer, because all servers within 
their tables will be at least two hops 
away. The workstation broadcasting 
the request acts on the first response 
it receives, ignoring all subsequent 
responses. 

Once the workstation has the name 
and address of the nearest server, it 
can request the fastest route to the 
server and try to establish a connec¬ 
tion. Once connected to a file server, 
the workstation can query that 
server’s bindery for the address of 
the server that it wants to log onto. 
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Figure 9. Routers Inform Other Routers When Going Down 
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Little Solutions 
for LANs 


Our Little Solutions column in 
this issue is a collection of hints 
and tips that will be helpful to 
those installing LANs. 


NETLOGON Service 

The NETLOGON service runs on all 
servers. This function must run on 
the domain controller for users to 
logon onto the domain. The primary 
task of NETLOGON is to validate 
users logging onto the network. The 
other major task is to update the 
NET.ACC on the other servers in 
the domain. The NETLOGON ser¬ 


vice must run on an additional 
server to get any updates to the 
NET.ACC file. This file contains all 
user IDs and their passwords, group 
names, and access profiles. 

NET8002 After Installing a 
CSD 

When the OS/2 Communications 
Manager is installed, default configu¬ 
ration files ACSCFG.CFG and 
ACSCFGUS.CFG are furnished. 
When a CSD is installed, new ver¬ 
sions of these files are copied over 
current ones. Installation instructions 
recommend that a copy of these files 
should be used with different names. 
If default files are used, current files 
are replaced with new ones, and all 
information in the old files is lost. 


The configuration file may get writ¬ 
ten over on a server network during 
CSD installation. The server will fail 
to start after the CSD is applied and 
the error message NET8002 is then 
displayed. If Communications Man¬ 
ager is used for host communica¬ 
tions, it must be reconfigured. 

Backing up NET.ACC File 

Here’s an easy way to keep a cur¬ 
rent backup copy of your NET. ACC 
file. Figure 1 contains an example of 
lines that could be used in the 
STARTUP.CMD. These three lines 
store copies of the NET. ACC from 
the last three reboots of the server. 
Use whatever file names you want 
for the backup files. Keep a 
NET.ACC backup for each server. 


COPY C:\IBMLAN\ACCOUNTS\NETBACK2.ACC C:\IBMLAN\ACCOUNTS\NETBACK3.ACC 
COPY C:\IBMLAN\ACCOUNTS\NETBACK 1 .ACC C:\IBMLAN\ACCOUNTS\NETBACK2.ACC 
COPY C:\IBMLAN\ACCOUNTS\NET.ACC C:\IBMLAN\ACCOUNTS\NETBACK 1 .ACC 


Figure 1. Backup of NET.ACC in STARTUP.CMD File 
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Users Unable to Get Access 
to Shared Resources 

If you can’t access a resource that 
should be available, there’s an easy 
way to see if it’s an access control 
restriction. Have the network admin¬ 
istrator go to the User Profile Man¬ 
agement (UPM) services menu and 
change the user ID type from “user” 
to “admin.” If the user can then gain 
access, the administrator needs to 
change the user’s security level to 
allow file access. 

Guest User ID 

There are some unique characteris¬ 
tics about the guest ID and guest 
group. Both RIPL and diskboot 
DLR machines need guest access to 
the IBMLAN\DOSLAN\NET direc¬ 
tory to get started on the network. 

If an APPLY has been executed 
above the NET directory, access to 
necessary files will be denied. The 
guest ID or DLR machine trying to 
start the network then displays a 
message indicating that the server is 
not available or cannot copy 
XSRW.BAT. To correct this error, 
have the administrator give the guest 
ID “R” access to the 
IBMLAN\DOSLAN\NET directory. 

An error will also occur if the guest 
ID has been deleted or was inadver¬ 
tently assigned a password. This can 
be resolved by adding back the 
guest ID or removing the password 
requirement for the guest ID. 


Running Laserjet II and III 
on a Network 

Network printing problems may 
occur while using the Laserjet II and 
III printers with the auto-continue 
function, which is a feature of the 
printer. While running on a network, 
these printers should have “Auto 
Continue” turned on even though 
the default for these models is off. 

An APPLY Function Tip 

The APPLY function should be used 
with care. This function should 
never be used on the root drive 
above the IBMLAN directory. 

Doing so changes access profiles for 
directories below the IBMLAN di¬ 
rectory. Users would then receive 


“access denied” messages when try¬ 
ing to use resources they could ac¬ 
cess before the APPLY was made. 
Users may also lose logon assign¬ 
ments. Access profiles are setup for 
these directories at installation, and 
any APPLY made afterwards 
changes profiles. (Note: An APPLY 
will not affect any files under the 
IBM LAN Directory when used with 
LAN Server 1.3.) 

Common Network Errors 
and Solutions 

Figure 2 shows some LAN 
Requester/Server error messages and 
possible solutions. 

- Monte Hall , IBM, Austin 


Error 

Solution 

NET3055 

Check the cable connecting the PC to the ring 

NET3055 

Make sure that the sessions and commands parameters 
in the NetBIOS section of the Communications Man¬ 
ager CFG file are larger than the sessions and com- 
mands parameters set on the NET1 line of the 
IBMLAN.INI file 

NET3056 

NET3195 

NET3062 

If this error is on an additional server, go through the 
resync procedure listed at the end of the READ.ME 
file on diskette 12 of CSD 4098 

NET9853 

Make sure the machine ID listed in the IBMLAN.INI 
at the requester is not the same as the user ID 


Figure 2: LAN Requester/Server Errors and Possible Solutions 
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Random Data 


New Products 

Hardware 

IBM Personal System/2 
Model 95 XP 486 (8595-0G9 
AND OGF) 

IBM is extending the Personal System/2 
(PS/2) Model 95 XP 486 family with 
two new entry models. These models are 
based on Micro Channel architecture and 
use the new i486SX™ (486SX) 20 MHz 
microprocessor. The 486SX consists of a 
32-bit 486 processor without the numeric 
co-processor unit. This results in an 
entry 486 processor that performs at 
speeds comparable to that of a 33 MHz 
386 processor. These entry models may 
be upgraded to the more powerful 
486/25 MHz or the 486/33 MHz proces¬ 
sors via the IBM PS/2 486/25 and 
486/33 Processor Upgrade Options. 

The PS/2 Model 95 XP 486 (8595-0G9) 
is a 486SX/20 MHz system with a 160 
MB SCSI fixed disk installed as the stan¬ 
dard direct access storage device. The 
PS/2 Model 95 XP 486 (8595-0GF) is a 
486SX/20 MHz system with a 400 MB 
SCSI fixed disk installed as the standard 
direct access storage device. In addition, 
these new models feature 4 MB of mem¬ 
ory standard on the system board. The 
new PS/2 Models 8595-0G9 and OGF, 
with the addition of 400 MB fixed-disk 
file options, can now provide up to 2 GB 
of internal data storage. This capacity 
better meets requirements for large data 
bases typical in local area network 
(LAN) server and multi-user host applica¬ 
tions. All other standard features, such as 
processor upgradeability, XGA graphics, 
memory optimization, and expandability 
attributes of the PS/2 Model 95 XP 486 
platform remain unchanged. 

Also, a 487SX co-processor is an¬ 
nounced, which allows numeric process¬ 


ing capabilities to be added to the 
486SX versions of the Models 90 and 
95. The IBM PS/2 Math Co-Processor 
487SX/20 MHz contains the new 
i487SX co-processor with installation in¬ 
structions packaged as an optional fea¬ 
ture. The i487SX replaces the i486SX 
processor and has all of the capabilities 
of the i486SX, plus integrated floating¬ 
point processing to enhance performance 
for compute-intensive applications. 

The operating systems supported by the 
PS/2 Model 95 XP 486 are OS/2 Stan¬ 
dard Edition Versions 1.2 and 1.3, OS/2 
Extended Edition Versions 1.2 and 1.3, 
DOS Versions 3.30 and 4.00, AIX PS/2 
1.2.1, and IBM 4680 Operating System 
Versions 2 and 3. 

Highlights: 

• New processor complex featuring the 
486SX/20 MHz microprocessor 

• 4 MB standard parity memory, ex¬ 
pandable to 32 MB on the system 
board 

• PS/2 SCSI 32-bit bus master adapter 
with cache 

• Up to 2 GB of internal high-speed 
data storage 

• Eight 32-bit Micro Channel expan¬ 
sion slots (one slot is used for the 
SCSI adapter and one is used for the 
XGA Display adapter/A) 

• Seven internal storage device bays 
supporting a combination of 3.5-inch, 
half-high drives and 5.25-inch, full- 
high drives 

• XGA Display Adapter/A with 512 
KB video memory 

• One DMA serial port and one DMA 
parallel port 

• Selectable boot and easy-to-upgrade 
licensed system programs 

Letter # 191-059, April 23, 1991 


IBM Personal System/2 
Model 95 XP 486 (8595-OJF 
AND 0KF) 

IBM is extending the Personal System/2 
(PS/2) Model 95 XP 486 family of sys¬ 
tems by providing even higher capacity 
fixed disk storage models. PS/2 Models 
8595-OJF and 0KF feature 486/25 MHz 
and 486/33 MHz 32-bit microprocessors, 
respectively, with a high-performance, 
400 MB SCSI fixed disk installed as the 
standard direct access storage device. In 
addition, these new models feature 8 MB 
of memory standard on the system 
board. The new PS/2 Models 8595-OJF 
and 0KF, with the addition of 400 MB 
fixed disk options, can now provide up 
to 2 GB of internal data storage. These 
options allow the the systems to better 
meet requirements for large data bases 
typical in local area network (LAN) 
server and multi-user host applications. 

All other technologically advanced, stan¬ 
dard features such as processor up¬ 
gradeability, Extended Graphics Array 
(XGA) graphics, memory optimization, 
and the expandability attributes of the 
PS/2 Model 95 XP 486 platform remain 
unchanged. 

The operating systems supported by the 
PS/2 Model 95 XP 486 are OS/2 Stan¬ 
dard Edition Versions 1.2 and 1.3, OS/2 
Extended Edition Versions 1.2 and 1.3, 
DOS Versions 3.30 and 4.00, AIX PS/2 
1.2.1, and IBM 4680 Operating System 
Versions 2 and 3. 

Highlights: 

• Processor complex featuring the 
80486/25 MHz or 33 MHz micropro¬ 
cessor 

• 8 MB standard parity memory, ex¬ 
pandable to 32 MB on the system 
board 

• PS/2 SCSI 32-bit bus master adapter 
with cache 
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• 400 MB SCSI fixed disk with 11.5 
ms average seek time 

• Up to 2 GB of internal high-speed 
data storage 

• Eight 32-bit Micro Channel expan¬ 
sion slots (one slot is used for the 
SCSI adapter, and one is used for the 
XGA Display Adapter/A) 

• Seven internal storage device bays 
supporting a combination of 3.5-inch, 
half-high drives and 5.25-inch, full- 
high drives 

• Enhanced Performance XGA Display 
Adapter/A standard, providing 1024 x 
768 resolution 

• One DMA serial port and one DMA 
parallel port 

• Selectable boot and easy-to-upgrade li¬ 
censed system programs 

Letter# 191-058, 4/23/91 

IBM Personal System/2 
Model 90 XP 486 (8590-0G5 
AND 0G9) 

IBM is extending the Personal System/2 
(PS/2) Model 90 XP 486 family with 
two new entry models. These models are 
based on Micro Channel architecture and 
utilize the new i486SX (486SX) 20 MHz 
microprocessor. The 486SX consists of a 
32-bit 486 processor without the numeric 
co-processor unit. This results in an 
entry 486 processor that performs at 
speeds comparable to that of a 33 MHz 
386 processor. These entry-level models 
may be upgraded to the more powerful 
486/25 MHz or the 486/33 MHz proces¬ 
sors via the IBM PS/2 486/25 and 
486/33 Processor Upgrade Options. If 
the user requires numeric-intensive pro¬ 
cessing capabilities, this function can be 
obtained by installing the IBM PS/2 
Math Co-Processor 487SX/20 MHz op¬ 
tional feature. 

The PS/2 Model 90 XP 486 (8590-0G5) 
is a 486SX/20 MHz system with a 80 
MB SCSI fixed disk drive installed as 
the standard direct access storage device. 
The Personal System/2 Model 90 XP 
486 (8590-0G9) is a 486SX/20 MHz sys¬ 


tem with a 160 MB SCSI fixed disk 
drive installed as the standard direct ac¬ 
cess storage device. In addition, these 
new models feature 4 MB of memory 
standard on the system board. The new 
PS/2 Models 8590-0G5 and 0G9, with 
the addition of 400 MB fixed disk file 
options can now provide up to 960 MB 
of internal data storage to better meet re¬ 
quirements. All other standard features 
such as processor upgradeability. Ex¬ 
tended Graphics Array (XGA) graphics, 
memory optimization and expandability 
attributes of the PS/2 Model 90 XP 486 
platform remain unchanged. 

The operating systems supported by the 
PS/2 Model 90 XP 486 are OS/2 Stan¬ 
dard Edition Versions 1.2 and 1.3, OS/2 
Extended Edition Versions 1.2 and 1.3, 
DOS Versions 3.30 and 4.00, AIX PS/2 
1.2.1, and IBM 4680 Operating System 
Versions 2 and 3. 

Highlights: 

• New processor complex featuring the 
486SX/20 MHz microprocessor 

• 4 MB standard parity memory, ex¬ 
pandable to 32 MB on the system 
board 

• Enhanced performance XGA graphics 
integrated on system board providing 
1024 x 768 resolution 

• Up to 960 MB of internal high-speed 
data storage 

• PS/2 SCSI 32-bit bus master adapter 
with cache 

• Four internal storage device bays sup¬ 
porting three, 3.5-inch half-high 
drives and one, 5.25-inch half-high 
drive 

• Four 32-bit Micro Channel expansion 
slots (one is used for the SCSI 
adapter) 

• Two DMA serial ports and one DMA 
parallel port 

• Selectable boot and easy to upgrade li¬ 
censed system programs 

Letter# 191-057, April 23, 1991 


IBM Personal System/2 
Model 30 286 (8530-E41) 

The Personal System/2 (PS/2) Model 30 
286 (8530-E41) system unit is a 45 MB 
fixed disk drive version of the Model 30 
286 and has 1 MB 120 ns memory stan¬ 
dard on the planar. The Model 30-E41 
utilizes the 80286 microprocessor operat¬ 
ing at 10 MHz with one wait state to sys¬ 
tem memory and has the following 
integrated functions: 

• Parallel port 

• Serial port 

• Pointing device port 

• Keyboard port 

• 1.44 MB diskette drive support 

• VGA graphics 

The operating systems supported by the 
Model 30-E41 are DOS Versions 3.30 
and 4.00, OS/2 Standard Edition Ver¬ 
sions 1.1, 1.2, and 1.3, and OS/2 Ex¬ 
tended Edition Versions 1.1, 1.2 and 1.3. 

Highlights: 

• 10 MHz 80286 processor 

• 80287 Math co-processor socket 

• 1 MB of standard memory - 16 MB 
addressability 

• 45 MB fixed disk capacity 

• VGA color graphics 

Letter# 191-060, April 23, 1991 

IBM Personal System/2 
486/25 and 486/33 Processor 
Upgrade Options 

The Personal System/2 (PS/2) 486/25 
Processor Upgrade Option enhances the 
announced Personal System/2 Model 90 
XP 486 (8590-0G5, -0G9) and Model 95 
XP 486 (8595-0G9, -0GF) by providing 
additional processor growth capability. 
The PS/2 486/25 Processor Upgrade Op¬ 
tion features the 32-bit Intel i486 proces¬ 
sor running at 25 MHz on a processor 
complex designed to upgrade the 
486SX/20 MHz or 487SX/20 MHz ver¬ 
sions of PS/2 Models 90 and 95. The 
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486SX/20 MHz or 487SX/20 MHz ver¬ 
sions of Models 90 and 95 can also be 
upgraded by the IBM PS/2 486/33 Pro¬ 
cessor Upgrade Option. These processor 
upgrade options significantly enhance 
the range of processor performance that 
can now be achieved with the expand¬ 
able processor concept introduced on the 
PS/2 Model 90 and 95 XP 486 systems. 

The 486/25 and 486/33 Processor Up¬ 
grade Options are supported by OS/2 
Standard Edition Versions 1.2 and 1.3, 
OS/2 Extended Edition Versions 1.2 and 
1.3, DOS Versions 3.30 and 4.00, AIX 
PS/2 Version 1.2.1, and the IBM 4680 
Operating System Versions 2 and 3. 

Highlights: 

• 25 MHz and 33 MHz 80486 32-bit 
microprocessors 

• Internal memory cache controller and 
8 KB internal memory cache 

• Internal floating-point processor unit 

• Allows processor upgrade in PS/2 
Model 90 XP 486 (8590-0G5, -0G9) 
and 95 XP 486 (8595-0G9, -0GF) sys¬ 
tems 

• Well-suited for compute and numeric¬ 
intensive applications and for heavy 
use multi-user, multitasking applica¬ 
tions 

Letter # 191-052, April 23, 1991 

Memory Enhancements for 
PS/2 Model 80 (8580-081, 

161, 321), Model 90 XP 
(8590-0J5, 0J9, 0KD) and 
Model 95 XP (8595-0J9, 

0JD, 0KD) 

IBM is enhancing the standard system 
memory to 4 MB on PS/2 Model 80 
(8580-081, 161, 321) systems. IBM is 
also enhancing the standard memory to 8 
MB on IBM Personal System/2 Model 
90 XP (8590-0J5, 0J9, 0KD) systems 
and Model 95 XP (8595-0J9, 0JD, 0KD) 
systems. 

These memory enhancements are avail¬ 
able at no additional charge. With this 
change, all enhanced systems have dou¬ 


bled the standard system memory to bet¬ 
ter address application requirements. 

Highlights: 

• Concurrent execution of more applica¬ 
tions with additional 2 MB of mem¬ 
ory in PS/2 Model 80 (8580-081, 

161, 321) 

• Concurrent execution of more applica¬ 
tions with additional 4 MB of mem¬ 
ory in PS/2 Model 90 XP (8590-0J5, 
0J9, 0KD) and Model 95 XP (8595- 
0J9, 0JD, 0KD) 

• No additional cost 
Letter# 191-056, April 23, 1991 

IBM Personal System/2 
SCSI Storage Enclosure and 
IBM Personal System/2 
Card to Option Cable 

The Personal System/2 (PS/2) SCSI Stor- 
age Enclosure (3510-0V0) is an external 
enclosure that can accommodate one 3.5- 
inch or 5.25-inch, half-high Small Com¬ 
puter Systems Interface (SCSI) storage 
device, such as a SCSI fixed disk drive. 
The enclosure features a 32-watt univer¬ 
sal power supply, a cover key lock as¬ 
sembly, and mounting holes in the base 
assembly for added security. When this 
enclosure is equipped with a SCSI stor¬ 
age device, it expands the storage capac¬ 
ity of a PS/2 Micro Channel desktop or 
floor-standing system. The enclosure ad¬ 
heres to the American National Standard 
Institute (ANSI) SCSI standard X3.131- 
1986, which supports up to seven SCSI 
devices attached to either PS/2 Micro 
Channel SCSI adapter. Multiple enclo¬ 
sures may be stacked to satisfy storage 
requirements for local area network 
(LAN) or other applications that require 
accessibility to large amounts of data. 

The PS/2 Card to Option Cable (#1140, 
6451139) replaces the current PS/2 Card 
to Option Cable (#1041, 6451041). This 
60-to-50-pin cable attaches the first exter¬ 
nal SCSI device to a PS/2 Micro Chan¬ 
nel SCSI adapter. The required PS/2 
Micro Channel SCSI Adapter Option In¬ 
terface Terminator, included with the 
PS/2 Card to Option Cable, is a 50-pin 


terminator installed on the last SCSI de¬ 
vice to terminate the SCSI bus. This new 
terminator must be used for the PS/2 
SCSI Storage Enclosure and for external 
SCSI devices attached in a “daisy-chain” 
fashion through the PS/2 Option to Op¬ 
tion Cable (#1042, 6451042). 

Highlights: 

• A versatile package that accommo¬ 
dates a wide range of 3.5-inch and 
5.25-inch, half-high SCSI storage de¬ 
vices 

• Features include cover key lock as¬ 
sembly, mounting holes in base for 
bolt down, external audio connection 
capability, and external SCSI ID selec¬ 
tor switches 

Letter# 191-053, April 23, 1991 

Enhanced M-Motion Video 
Adapter/A for the IBM 
Personal System/2 

The M-Motion Video Adapter/A (#1991, 
95F1091) is a display adapter for Per¬ 
sonal System/2 (PS/2) system units with 
Micro Channel architecture. With this 
adapter, full-motion interactive color 
video, and VGA graphics and text can 
be displayed on a standard PS/2 color 
display. The M-Motion Video Adapter/A 
also provides full-line audio input/output 
capabilities with limited quality digital re¬ 
cord/playback. Composite Sync (CS) out¬ 
put is available to synchronize up to 
three compatible video input sources at 
the same time. The new M-Motion 
Video Adapter/A (#1991,95F1091) re¬ 
places the original M-Motion Video 
Adapter/A (#3487, 34F3087). 

M-Motion Video Adapter/A software 
and an installation software diskette pro¬ 
vide interactive diagnostics. Composite 
Sync loop test is available through ad¬ 
vanced diagnostics. The installation soft¬ 
ware is compatible with DOS and OS/2 
operating systems. M-Control Pro¬ 
gram/2, Audio Visual Connection) 

(AVC) Version 1.03, Storyboard™ 

Live!, and LinkWay™ are supported by 
the M-Motion Video Adapter/A. 
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Highlights: 

• Increases user performance while re¬ 
ducing rework 

• Improves availability and access to 
data 

• Enables personal computing 

• Saves personnel training time through 
reduction in complexity 

• Supports business objectives 

• Improves productivity 

• Manages rate of change 

• Supports application development 

Letter# 191-037, April 2, 1991 

Software 

IBM Hollywood Version 1.0 

Hollywood™ is a presentation graphics 
software product to help presenters in 
business, government, and education cre¬ 
ate star-quality presentations with ease. 
Hollywood includes powerful text capa¬ 
bilities and extensive charting tools that 
can create a wide variety of data charts, 
such as bullet, pie, bar, tables, and orga¬ 
nization charts. In addition, a complete 
set of drawing tools is available for anno¬ 
tating charts and creating diagrams. 

Hollywood is planned as a family of pre¬ 
sentation graphics products. The Win¬ 
dows 3.0 version of Hollywood was 
announced on May 7, 1991. In addition, 
IBM intends to provide a version of Hol¬ 
lywood for the OS/2 Presentation Man¬ 
ager environment. 


Highlights: 

• Creates complete presentations: trans¬ 
parencies, slides, paper, handout 
notes, speaker notes, and on-screen 
presentations 

• Creates data, graph, and word charts 
in most forms 

• Creates a presentation from an outline 

• Has drawing capabilities 

• Works with most graphic file formats 

Letter #291-214, May 7, 1991 

IBM Stories and More 

Stories and More includes interactive, 
mouse-driven activities, which extend an 
early reader’s experience with literature. 
The Teaching and Learning with Com¬ 
puters (TLC) teacher support materials 
accompanying this product extends 
IBM’s Integrated Language Arts TLC ap¬ 
proach to computer use in the classroom. 

Highlights: 

• Literature-based reading approach 
helps foster a sense of excitement for 
stories and helps build an apprecia¬ 
tion for the power of language 

• Engaging reading voices bring the lit¬ 
erature alive, giving greater meaning 
to the text of the stories 

• Interactive mouse provides alternative 
to keyboard and enhances student in¬ 
terest 

• Story activities build reading compre¬ 
hension by asking students to recall, 
analyze, and interpret what they read, 
and then compare the new informa¬ 
tion to what they already know 

Letter #291-216, May 7, 1991 


IBM Touch Typing for 
Beginners Version 2.00 

IBM Touch Typing for Beginners Ver¬ 
sion 2.00 is designed to teach correct fin¬ 
ger placement and touch typing, provide 
practice for all letters, numerals and 
most function keys, and help improve 
typing speed and accuracy. The program 
is recommended for second grade and 
above, but may be used by anyone wish¬ 
ing to improve basic typing skills. Color¬ 
ful animated graphics make full use of 
PS/2 capabilities. The program runs 
stand-alone or in a networked environ¬ 
ment. 

The program supports a commitment to 
the Teaching and Learning with Comput¬ 
ers (TLC) approach for computer use in 
the classroom while giving students key¬ 
boarding skills required by Writing to 
Read, Writing to Write, and all IBM 
Basic Skills courseware. 

Highlights: 

• Improves basic typing skills through 
the use of motivating games, beautiful 
graphics, and an easy-to-use menu 
system 

• Enhances learning through a self- 
paced, sequential lesson design 

• Provides teachers with customization 
capabilities 

• Enriches the product offerings sup¬ 
ported by the Teaching and Learning 
with Computers integrated approach 

• Functions on all models of PS/2s in a 
stand-alone or network environment 

• Appropriate for a wide range of stu¬ 
dent abilities 

Letter #291-137, April 2, 1991 
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Suspend and resume adds convenience to the L40 SX Laptop, (page 6) 


4 4 The OS/2 2.0 shell has been redesigned to give users a single 
interface to manage multiple types of objects, (page 10) 


44 When porting applications to either OS/2 or AlX PS/2 from 

D OS, all system calls must be recoded, (page 31) _ 


With dual displays, users can focus on the PM screen earlier than normal 
when switching back to the PM session, (page 42) 


Today, a personal computer puts more power on your desk 
than resided in the “glass house” of the 1960s. (page 43) 


44 Throughout our time in Arizona, the STS and BUSMON PS/2s were attached with 

duct tape to a missile launcher, which was on the side of the helicopter, (page 48 ) 


DCAF adds a new dimension - electronic monitoring from 
anywhere on the network, (page 58) 


IBM’s STP cables can support high data rate transmissions because of the shield 
that protects the environment from electromagnetic interference, (page 59) 


44 The IBMLAN.INI BIGBUFS provide a way to 
control memory utilization, (page 64) 


Basically, seven different protocols are used for communication and 
packet routing within the native NetWare environment, (page 68) 
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